Как найти причину перегрузки после очистки кеша, восстановить работу каталога и проверить, что покупатели снова могут завершать заказы.
от очистки к восстановлению
После очистки кеша интернет-магазин может начать медленно открывать категории, задерживать добавление товаров в корзину и выдавать ошибки при оформлении. Посетителей вроде бы столько же, а PHP и база данных уже не справляются. Такое возможно, когда запросы, которые раньше получали готовый результат, начинают заново запускать вычисления.
Чтобы найти причину, сопоставьте три изменения: что произошло с кешем, сколько работы стало доходить до приложения и где увеличилось время обработки. Одного графика процессора или количества посетителей недостаточно. Нужно установить, кеш ещё заполняется, перестал сохраняться, повторно очищается или пересоздаётся слишком многими процессами одновременно.
Дальше разберём проверку магазина после очистки серверного кеша или CDN. Для владельца это порядок сбора фактов и контроля восстановления. Для администратора и разработчика — ориентиры в журналах, настройках и показателях приложения.
Что зафиксировать до следующей очистки или перезапуска
Повторное нажатие «Очистить всё» может снова удалить уже восстановленные данные. Перезапуск сервисов способен сбросить накопленные показатели и временно изменить симптомы. Сначала сохраните доступные наблюдения. Если магазин уже недоступен, сбор сведений не должен задерживать необходимую аварийную помощь.
- Точное время первой очистки и появления задержек, с часовым поясом.
- Кнопку, команду, плагин или задание, которое выполнило очистку, и затронутые типы кеша.
- Другие изменения рядом по времени: обновление модуля, импорт каталога, смену настроек CDN, пересоздание изображений, перезапуск PHP.
- Несколько проблемных адресов и действий: открытие категории, выбор фильтра, изменение корзины, отправку заказа.
- Графики и журналы за период до события, во время сбоя и после первого исправления.
Сохраните действующие настройки перед их изменением. Для обращения к специалисту достаточно адреса магазина, времени события и описания симптомов; пароли, содержимое сессий и платёжные данные не нужно прикладывать к открытому сообщению.
Если связь с очисткой пока не подтверждена, проверьте и другие причины недоступности. Общий порядок различения атаки и внутренней перегрузки разобран в статье «DDoS или серверный сбой». Здесь основное внимание уделим состоянию кеша и работе, которую он перестал снимать с приложения.
Какой кеш очистили и что теперь выполняется заново
На одном магазине могут одновременно работать несколько механизмов кеширования. Название кнопки в панели не всегда показывает весь масштаб действия: плагин способен очистить собственные файлы и отправить запрос внешнему сервису. Уточните фактические действия по журналу и настройкам интеграции.
Кеш, в котором ещё нет нужных данных, называют холодным. Его прогрев — это создание и сохранение результатов для последующих обращений. Прогрев может происходить по запросам посетителей или через специальное задание.
На узком экране таблицу можно прокрутить по горизонтали.
| Уровень | Что хранит | Что проверить после очистки |
|---|---|---|
| Браузер покупателя | Локальные копии ответов и ресурсов. | Очистка в одном браузере не очищает серверный кеш магазина. Не смешивайте эти события. |
| CDN | Ресурсы и, при соответствующей настройке, HTML на внешних узлах. | Как изменились обращения к исходному серверу и какие типы ответов потеряли кеш. |
| Кеш страниц | Готовый HTML для разрешённых публичных страниц и вариантов. | Сохраняется ли ответ и используется ли он при следующем сопоставимом запросе. |
| Кеш объектов и компонентов | Результаты выборок, вычислений и отдельных блоков приложения. | Повторяются ли дорогие операции, работает ли хранилище, не удаляются ли записи снова. |
| PHP OPcache | Скомпилированный байткод PHP. | Был ли сброс или перезапуск. Этот кеш не заменяет готовые страницы и результаты SQL. |
Отдельно проверьте производные файлы: миниатюры изображений, объединённые стили и другие ресурсы, которые магазин создаёт по запросу. Их массовое удаление может увеличить нагрузку на процессор и диск даже без заметного роста SQL-запросов.
Если CDN продолжает отдавать картинки из кеша, это ещё не подтверждает исправность кеширования каталога. Если страница пришла из кеша HTML, её последующие запросы за ценой, остатком или корзиной всё равно могут обращаться к приложению. Оценивайте нужную операцию целиком.
Почему обычная посещаемость превращается в перегрузку
До очистки многие обращения могли завершаться на CDN или получать готовую страницу на сервере. После очистки часть того же потока начинает выполнять PHP, выбирать товары, рассчитывать блоки каталога и обращаться к базе. Меняется количество и стоимость обработки запросов, хотя число покупателей может оставаться прежним.
Сравнивайте одинаковые интервалы и группы адресов. Отдельно учитывайте HTML каталога, поиск и фильтры, фоновые запросы корзины, статические файлы, интеграции и автоматический прогрев. Увеличение доли тяжёлых фильтров способно изменить нагрузку даже при неизменном общем числе запросов.
Сеансы аналитики не равны обращениям к серверу. Один покупатель выполняет несколько действий, а задания прогрева и интеграции могут вообще не попадать в отчёты посещаемости. Данные CDN, веб-сервера и приложения тоже имеют разные границы: часть запросов обслуживается раньше, чем доходит до следующего слоя.
Для выбранной группы страниц сопоставьте входящий поток, обращения к приложению, время ответа и состояние очередей. Если после очистки выросли именно обращения к PHP, затем появились задержки SQL и очередь обработки, это обоснованное направление расследования. Совпадение по времени ещё нужно проверить по конкретным операциям и изменениям.
Как проверить заполнение кеша
Выберите публичную категорию или карточку товара, которая по правилам магазина должна кешироваться. Зафиксируйте адрес, параметры, язык, валюту, состояние авторизации и cookies. Выполните несколько обычных GET-запросов с небольшими интервалами и посмотрите заголовки ответа, содержимое и время загрузки.
Не добавляйте случайные параметры к адресу: они могут создавать новые варианты кеша. Не используйте принудительную перезагрузку браузера как единственный тест — она способна отправить условия повторной проверки. Убедитесь, что ответ получен по сети, а не взят из памяти браузера. Сам тест не должен превращаться в нагрузочный обход магазина.
Один ответ MISS после очистки ожидаем. Для одного варианта страницы последующие попадания в кеш, снижение обращений к приложению и сокращение задержек показывают, что восстановление идёт. При нескольких узлах CDN или серверных экземплярах сравнивайте по возможности один маршрут запроса: разные узлы могут заполняться независимо.
Названия заголовков и статусов зависят от системы. В Cloudflare CF-Cache-Status: HIT означает получение ресурса из кеша этого сервиса. MISS указывает на отсутствие подходящей кешируемой копии, BYPASS — на отказ кешировать ответ, а DYNAMIC — на решение не использовать кеш для запроса. Классификация некешируемых ответов менялась в 2026 году; старые инструкции могут трактовать повторяющийся MISS иначе.
BYPASS на персональной странице может быть правильным поведением. На публичной странице, которую ожидали кешировать, проверяйте правила, ответные заголовки, установку cookies и ключ кеша. Ключ определяет, какие запросы используют одну копию: разные параметры, язык или валюта могут создавать разные записи. Объединять варианты без проверки содержимого опасно для корректности цен и персональных условий.
Заголовок внешнего сервиса описывает только его слой. Чтобы понять, выполнялся ли PHP за ним, нужны журналы следующего участка. Отсутствие диагностического заголовка также не доказывает отсутствие кеширования: конкретная система может его не отдавать.
Как различить причины замедления после очистки
Похожие внешние симптомы требуют разных исправлений. Используйте таблицу для выбора проверки, затем подтверждайте предположение журналами и повторяемым результатом.
На узком экране таблицу можно прокрутить по горизонтали.
| Сценарий | Наблюдаемый признак | Следующая проверка |
|---|---|---|
| Кеш постепенно заполняется | Для сопоставимых запросов появляются попадания, обращения к приложению и задержки снижаются. | Проверить тенденцию по важным страницам и убедиться, что покупатели могут завершать действия. |
| Один результат создают параллельно | После промаха одновременно повторяются одинаковые дорогие операции. | Сопоставить ключ или параметры вычисления, время запуска и повторные обращения к БД. |
| Кеш не сохраняется или быстро теряется | Один разрешённый вариант постоянно требует полной обработки. | Проверить запись, доступность хранилища, срок хранения, вытеснение и правила кеширования. |
| Кеш сбрасывается повторно | Восстановление сменяется новым ростом промахов рядом с импортом или заданием. | Найти событие очистки и установить его инициатора и область действия. |
| Перегружает прогрев | Рост нагрузки совпадает с обходом страниц задачей предварительной загрузки. | Сопоставить журнал задания с запросами и контролируемо уменьшить его параллельность. |
| Обнаружилась дорогая операция | Отдельные страницы тяжело формируются даже при ограниченном числе обращений. | Измерить время обработчика, SQL, ожидания внешних сервисов и файловых операций. |
Одновременное пересоздание одного отсутствующего результата называют cache stampede. Массовая очистка повышает вероятность такого сценария, но рост промахов сам по себе его не доказывает. Разные страницы могут выполнять разные тяжёлые вычисления; тогда ограничение обновления одного ключа не решит всю проблему.
Не назначайте универсальное время «нормального прогрева». Оно зависит от числа вариантов, посещаемости, стоимости создания данных и доступных ресурсов. Ориентиром служит наблюдаемое восстановление при допустимых задержках, а не ожидание произвольных десяти минут.
Передайте адрес магазина, время очистки и описание действий, которые стали работать медленно. По этим сведениям согласуем проверку кеша, приложения и базы.
Где сопоставить обращения к приложению и нагрузку на базу
Журналы сервера и приложения
Для проблемных адресов сопоставьте время, метод, параметры, HTTP-статус, длительность ответа и сведения о прохождении к следующему обработчику. В NGINX при соответствующем формате журнала полезны $upstream_cache_status, $request_time и $upstream_response_time. Их смысл зависит от конфигурации, повторных попыток и используемого обработчика.
Не считайте любой запрос к исходному серверу запуском PHP: он может завершиться на серверном кеше или выдаче файла. Если журнал не содержит нужных полей, отметьте это ограничение. Для дальнейшего наблюдения можно добавить ограниченный сбор данных по согласованию с администратором.
Очередь PHP
В PHP-FPM посмотрите listen queue, свободные и занятые процессы. Повторяющаяся очередь при отсутствии свободных обработчиков подтверждает ожидание выполнения. Поле max children reached отражает достижение предела после запуска пула; оно не показывает текущую очередь. Учитывайте время запуска: после перезапуска показатели сбрасываются.
Увеличение числа обработчиков требует расчёта памяти и возможностей базы. Если каждый процесс ждёт одну дорогую операцию, дополнительные процессы могут усилить конкуренцию за ресурсы. Служебную страницу состояния следует держать доступной только администраторам.
SQL и хранилище объектов
В базе сравнивайте частоту выполнения запросов, их суммарное время, длительность отдельных операций и ожидания блокировок. Один дорогой запрос и множество повторений относительно короткого запроса требуют разного исправления. Журнал медленных запросов помогает найти долгие операции, но не показывает автоматически все частые короткие запросы; для них нужны агрегированная статистика или наблюдение на уровне приложения.
Используйте уже собранные данные мониторинга, профилировщика и журналов. Новый сбор на перегруженном сервере ограничивайте по времени и объёму, контролируя место на диске. Добавлять индексы или менять SQL следует после анализа конкретной операции и проверки изменения.
Если используется Redis, полезны попадания и промахи при поиске ключей, вытеснение записей из-за ограничения памяти и ошибки записи. Сравнивайте прирост счётчиков за выбранный интервал. Общий показатель Redis может включать другие приложения и служебные ключи; он не равен доле HTML-страниц, отданных из кеша.
Перед удалением данных уточните назначение хранилища. Команда общей очистки Redis затрагивает все ключи в своей области действия, а не только кеш выбранного плагина. Если там хранятся сессии или задания, последствия выйдут за пределы ускорения страниц.
Если процессор занят обработкой изображений, а SQL почти не изменился, исследуйте генерацию файлов. Если PHP ждёт внешний сервис, начните с этого ожидания. Очистка помогает определить момент появления проблемы, но измерения должны показать, где выполняется лишняя работа.
Что дополнительно проверить в WooCommerce и Битриксе
В WordPress и WooCommerce разделите кеш страниц, постоянный объектный кеш и временные данные магазина. Наличие Redis на сервере ещё не подтверждает, что WordPress использует его между запросами. Проверьте подключение соответствующего механизма, ошибки и фактическое сохранение данных. Очистка временных данных WooCommerce и очистка HTML плагином — разные операции.
Посмотрите, не запускает ли обновление товара, темы или стороннего плагина повторную полную очистку. Для WP Rocket отдельно сопоставьте задания предварительной загрузки и генерации CSS с нагрузкой. User-Agent помогает найти предполагаемый источник, но подтверждайте его журналом задания и временем запуска. Снижение скорости прогрева проверяйте отдельно от других изменений.
В Битриксе различайте кеш компонентов, управляемый кеш и HTML-кеш. Уточните настройки проблемного компонента и условия, при которых его результат пересоздаётся. Проверьте события обмена с 1С, изменение товаров, агентов и собственные обработчики. Не каждое обновление каталога обязано приводить к сбросу всего магазина; это нужно установить по реализации.
Если файловый кеш не создаётся, проверьте место на диске, доступность каталога для процесса приложения и ошибки записи. Если он создаётся и сразу исчезает, ищите удаляющий процесс. Исправление должно сохранять обновление цен и остатков: бессрочное отключение инвалидации только заменит проблему производительности проблемой актуальности данных.
Как восстановить магазин с контролем нагрузки
Ограничить подтверждённый источник повторной работы
Если установлено, что перегрузку поддерживает массовый прогрев или повторная полная очистка, сначала ограничьте именно этот процесс. Приостановку импорта цен или остатков согласуйте с ответственным за магазин: устаревшие данные влияют на продажи. Не отключайте обработку оплаченных заказов и уведомлений вместе со всеми фоновыми заданиями.
Зафиксируйте временную меру, её срок и способ возврата. После изменения повторите исходную проверку и сравните показатели при сопоставимом потоке запросов.
Восстановить сохранение нужных данных
Устраните подтверждённую причину постоянных промахов: ошибку записи, недоступное хранилище, некорректное правило или слишком широкую очистку. Проверяйте один разрешённый вариант публичной страницы до расширения работ.
При откате настройки или кода учитывайте новые заказы и изменения данных. Возврат старой базы магазина ради восстановления кеша может потерять операции, появившиеся после резервной копии. План возврата должен описывать, что именно откатывается и какие текущие данные сохраняются.
Прогревать публичные страницы небольшими порциями
Выберите главные посадочные страницы, востребованные категории и товары по фактическим посещениям. Начните с небольшой параллельности. Увеличивайте её только после наблюдения за временем ответа, очередью PHP, БД и ошибками. Универсального безопасного числа потоков для всех магазинов нет.
Не включайте в такой обход действия добавления в корзину, персональные страницы и бесконечные сочетания фильтров. Список URL и варианты должны соответствовать правилам кеширования. Прогрев прекращают или замедляют, если задержки и очереди растут либо нарушается оформление заказа.
Уменьшение числа покупательских запросов из-за недоступности магазина может само снизить CPU. Поэтому снижение нагрузки оценивайте вместе с успешными ответами, продолжающимся обслуживанием посетителей и выполнением нужных действий.
Ограничить одновременное пересоздание одного результата
Для NGINX существуют отдельные механизмы proxy_cache_lock и fastcgi_cache_lock в зависимости от используемого слоя. Они позволяют ограничивать параллельное заполнение одной записи. Нужно учитывать ключ кеша, время ожидания и поведение при длительном обновлении: после предусмотренных тайм-аутов дополнительные запросы могут пройти дальше.
Для объектов внутри приложения требуется свой механизм согласования обновления. Блокировка кеша страниц не устраняет автоматически повторные вычисления объекта, который используют разные страницы. Изменение проверяют на конкретной операции и при отказе обновляющего процесса.
Выбирать допустимый способ обновления кеша
Точечная очистка затронутых адресов или сущностей уменьшает масштаб пересоздания. Если система поддерживает выдачу прежней публичной копии во время обновления, определите, для каких данных и на какой срок это допустимо. Персональные ответы, корзину и оформление нельзя превращать в общий кеш ради снижения нагрузки.
Удаление копии и пометка её как устаревшей имеют разные последствия. В Cloudflare доступна инвалидация с повторной проверкой у источника: при поддержке условных запросов и ответе 304 можно использовать сохранённое содержимое. Однако запрос к источнику всё равно происходит; экономию вычислений нужно измерять. Если проверка актуальности сама запускает тяжёлую сборку страницы, экономия передачи не означает такого же снижения нагрузки PHP.
Выдача прежней копии при обновлении требует наличия этой копии. После полного удаления вернуть её таким механизмом уже нельзя. Возможность показа старых цен и остатков оценивают отдельно, а итоговые условия покупки должны проверяться сервером при оформлении.
Как измерить пользу исправления
Оцените результат на трёх уровнях: сколько работы снимается с приложения, насколько быстрее и надёжнее выполняются действия, удаётся ли завершать покупки. Для этого нужны исходные количества запросов и операций, период измерения и одинаковые правила расчёта. Процент без размера выборки и описания условий мало помогает оценить результат.
Сравнивайте время ответа через медиану p50 и 95-й процентиль p95. Медиана описывает середину распределения. p95 — граница, которую не превышают примерно 95% измеренных значений; остальные ответы могут быть медленнее. Среднее способно скрыть задержки небольшой части покупателей. Указывайте число измерений, отдельно рассматривайте успешные ответы и отказы, сохраняйте сведения о тайм-аутах.
Общий p95 нескольких серверов нельзя получить простым средним их p95. Используйте объединённые исходные измерения или корректно агрегированные гистограммы. Оценка по гистограмме зависит от её разрешения; лишние знаки после запятой не делают результат точнее.
Для сравнения пригодны следующие показатели:
- Обращения к PHP на 1000 входящих HTML-запросов. Разделите число запусков приложения, связанных с выбранной группой запросов, на число входящих запросов этой группы и умножьте на 1000. Автоматический прогрев и фоновые задания учитывайте отдельно. Показатель помогает сравнивать объём работы при разной посещаемости.
- Доля технических отказов. Делите число запросов с выбранным типом сбоя на все соответствующие запросы в одной точке наблюдения. Правила учёта ошибок и тайм-аутов должны оставаться одинаковыми. Указывайте и долю, и исходные количества.
- Работа базы на одно действие. Сопоставляйте число SQL-запросов и их суммарное время для одного обработчика. Сумма длительностей параллельных запросов может превышать длительность самого действия; это разные показатели.
- Доля завершённых оформлений. Сопоставляйте уникальные начатые сценарии с созданными и оплаченными заказами, сохраняя один способ учёта и период ожидания платежа. Повторные нажатия и HTTP-запросы не должны считаться отдельными покупателями.
Относительное снижение показателя вычисляют как разницу между значениями до и после исправления, делённую на значение до исправления и умноженную на 100%. При нулевом исходном значении такой расчёт неприменим. Для долей дополнительно указывайте изменение в процентных пунктах — простую разницу процентных значений.
Сравнение дневного сбоя с тихой ночной работой не отделяет эффект исправления от изменения нагрузки. Сохраняйте сопоставимые группы страниц, устройства, авторизацию и состав запросов; отмечайте изменения рекламы, цен и наличия товаров. Несколько повторных интервалов помогают проверить устойчивость результата. При малом числе оформлений показывайте исходные количества и не объявляйте кратковременное колебание доказанным ростом конверсии.
Для бизнеса подтверждённая польза — восстановление нужных действий и уменьшение связанных отказов при рабочей нагрузке. Снижение CPU не равно такому же снижению стоимости хостинга, а рост числа заказов после исправления сам по себе не измеряет его вклад в выручку.
Что показывает опубликованный тест NGINX
В тесте, опубликованном NGINX 18 декабря 2015 года, для приложения WordPress сравнили короткое кеширование с дополнительным ограничением параллельного заполнения и выдачей прежней копии во время обновления. При параллельности 10 запросов и прогонах около 30 секунд пропускная способность выросла с 600,73 до 2185,03 запроса в секунду — примерно в 3,64 раза.
Это исторический результат конкретного стенда, а не статистика действующих магазинов или прогноз ускорения вашего сайта. Он показывает возможную разницу между наличием кеша и согласованным обновлением записей. Для собственного магазина эффект подтверждают его измерениями, включая персональные сценарии и оформление заказа.
Какие показатели сравнить до и после исправления
Сопоставляйте данные до очистки, во время сбоя и после изменения для одной группы страниц или операции. Укажите периоды с часовым поясом и используйте одинаковую длительность интервалов. Таблица поможет понять, какие наблюдения указывают на проблему и чем подтвердить результат исправления.
На узком экране таблицу можно прокрутить по горизонтали.
| Что сравнивать | Признак проблемы или ошибка сравнения | Как подтвердить результат |
|---|---|---|
| Условия измерения | Сравниваются разные страницы, состояние авторизации, состав запросов или интервалы разной длительности. | Повторить проверку в сопоставимых условиях. Отметить время исправления и другие изменения, способные повлиять на результат. |
| Входящие HTML-запросы | Посещаемость выглядит прежней, но выросла доля тяжёлых фильтров или добавились запросы прогрева и интеграций. | Разделить потоки по назначению. Убедиться, что снижение нагрузки сопровождается обслуживанием покупателей, а не падением числа запросов. |
| Обращения к PHP на 1000 HTML-запросов | Для сопоставимой группы публичных страниц больше запросов требует выполнения приложения. | Подтвердить уменьшение лишних запусков PHP для той же группы страниц. Фоновые задания и автоматический прогрев учитывать отдельно. |
| Статусы кеша нужного слоя | Один разрешённый вариант страницы постоянно даёт промахи или повторно теряет сохранённую копию. | Повторные сопоставимые запросы используют кеш по правилам магазина. Персональные ответы и оформление остаются корректными. |
| p50 и p95 времени ответа | Растёт p95: часть ответов заметно задерживается, даже если медиана изменилась мало. | Сравнить оба показателя и число измерений при рабочей нагрузке. Отдельно учитывать отказы и тайм-ауты, чтобы их исключение не создало ложное улучшение. |
| Число и доля технических отказов | Увеличиваются ошибки или тайм-ауты на затронутых страницах и действиях. | Доля отказов снижается при сопоставимом потоке запросов. Исходные количества и правила учёта ошибок сохранены. |
| Очередь PHP и занятые обработчики | Очередь устойчиво растёт, свободных обработчиков нет, запросы ждут выполнения. | Очередь сокращается и не накапливается снова при рабочей нагрузке. Учитывается время запуска пула и сброса счётчиков. |
| Частота и суммарное время SQL | Для одного действия повторяются одинаковые дорогие запросы или растёт суммарная работа базы. | Подтвердить исчезновение лишних повторений и сокращение работы базы на сопоставимое действие при правильном результате операции. |
| Начатые оформления и заказы | Покупатель начинает оформление, но заказ не создаётся, платёж не отражается в магазине или появляются дубли. | Сверить начатые сценарии, созданные заказы, платежи и итоговые статусы. Проверить отсутствие дублей; соблюдать единый период ожидания оплаты. |
| Следующий импорт или обновление кеша | После временного улучшения задержки возвращаются рядом с импортом, истечением срока хранения или повторной очисткой. | Наблюдать магазин в период штатного события, ранее вызывавшего сбой. Подтвердить актуальность каталога и отсутствие повторной перегрузки. |
Результаты измерений сохраните в рабочем отчёте вместе со ссылками на журналы, идентификатором изменения и ответственным. Вывод должен связывать событие, механизм перегрузки, исправление и результат повторной проверки. Если исходных данных нет или часть цепочки не подтверждена, укажите это прямо и зафиксируйте, какие наблюдения ещё нужны.
Как проверить покупки и обновление каталога
Проверка заканчивается не на открытии главной страницы. Пройдите основные действия в чистой гостевой сессии и в предусмотренных магазином вариантах авторизации. Тест оплаты выполняйте согласованным способом, чтобы не создавать лишние списания и дубли заказов.
На узком экране таблицу можно прокрутить по горизонтали.
| Проверка | Что выполнить | Что подтвердить |
|---|---|---|
| Категории и товары | Повторить обращения к выбранным публичным страницам. | Ожидаемое кеширование и приемлемое время ответа при рабочем потоке. |
| Поиск и фильтры | Проверить используемые покупателями условия и сортировки. | Верную выдачу без роста очередей и повторения связанных ошибок. |
| Корзина | Добавить товар, изменить количество и вариант. | Собственный состав, актуальную сумму и сохранение изменений. |
| Оформление | Выбрать доставку и доступный способ оплаты. | Правильный расчёт и создание одного ожидаемого заказа. |
| Оплата и учёт | Проверить согласованный платёжный сценарий и обработку уведомления. | Соответствие платежа, заказа и итогового статуса. |
| Изменение каталога | Проверить штатное обновление выбранного товара. | Обновление нужных данных без непредусмотренного сброса всего кеша. |
Разделяйте успешный ответ HTTP и завершённую операцию. Страница с кодом 200 может содержать сообщение об ошибке, а отправленное уведомление об оплате ещё должно быть обработано магазином. Проверяйте состояние заказа в системе учёта.
После проверки наблюдайте магазин в течение периода, который охватывает обычную нагрузку и событие, ранее вызывавшее сбой: импорт, истечение срока кеша или штатное обновление. Не устраивайте повторную массовую очистку на работающем магазине только ради доказательства. Испытания холодного состояния лучше проводить на подготовленном окружении; его отличия от рабочего сервера нужно учитывать.
Как подготовиться к следующей очистке
Для обновлений каталога и выпусков кода определите, какие данные должны стать неактуальными и кто запускает их пересоздание. Проверьте, не выполняют ли несколько плагинов или заданий одну и ту же полную очистку. Для тяжёлых процессов предусмотрите защиту от перекрывающихся запусков.
Запишите область очистки, список приоритетных страниц, ограничение прогрева, наблюдаемые показатели и условия остановки. Если используется несколько узлов приложения, учитывайте размещение кеша на каждом из них. При проверке производительности включайте как заполненный кеш, так и контролируемое восстановление после его обновления.
Срок хранения выбирают по требованиям к актуальности и стоимости пересоздания. Разнесение обновлений во времени может уменьшить одновременную нагрузку, но требует проверки на используемом механизме. Цена, остаток и персональные условия не должны оставаться неверными ради удобного графика сервера.
Частые вопросы
Нужно ли снова очищать кеш при замедлении магазина
Только если установлено, какие некорректные данные требуется удалить и как магазин выдержит их пересоздание. Повторная полная очистка без диагноза может начать восстановление заново и усилить нагрузку.
Можно ли просто дождаться прогрева
Наблюдение оправдано, если нужные страницы начинают обслуживаться из кеша, задержки и очереди уменьшаются, а покупатели могут завершать действия. Если данные не сохраняются, постоянно сбрасываются или прогрев перегружает сервер, ожидание не устраняет причину.
Поможет ли более мощный сервер
Дополнительные ресурсы иногда нужны для восстановления и роста магазина. Решение принимают по измерениям памяти, процессора, диска и базы. Повторная очистка, ошибочное правило или некорректная работа с кешем требуют собственного исправления.
Достаточно ли проверить долю попаданий в кеш
Проверьте, какие запросы входят в показатель. Картинки могут обслуживаться хорошо, пока важная категория или оформление работают медленно. Нужны данные по затронутым операциям и по тому слою, который должен снимать с них нагрузку.
Что делать при доступе только к панели магазина и хостинга
Зафиксируйте время, действие очистки, проблемные адреса, сообщения об ошибках и доступные графики. Попросите хостинг проверить обработчики PHP, ограничения ресурсов и журналы за этот период. Отсутствие доступа к БД не мешает начать расследование с точного описания события.
Если магазин продолжает замедляться после очистки
Для диагностики нужны адрес магазина, время события, название инструмента очистки и действия покупателей, которые перестали работать. По этим сведениям можно определить необходимые журналы и согласовать проверку кеширования, приложения и базы данных.
Если сбой сопровождается серверными ошибками, можно обратиться за диагностикой и устранением ошибок сайта. Через контакты VozniNet передайте описание ситуации. Результат работы следует фиксировать конкретно: подтверждённая причина, внесённые изменения, выполненные проверки и оставшиеся ограничения.