Нагрузка в Drupal: что проверять, когда сайт тормозит

Сначала выясните, что именно перестало справляться

Когда в Drupal растёт время ответа или появляются ошибки 502 и 504, причина не обязательно в самом Drupal. Запрос может ждать свободного PHP-процесса, выполнять тяжёлую выборку в базе или каждый раз заново собирать страницу, которую можно было отдать из кеша. Если сразу увеличить число PHP-FPM-процессов, очередь может уменьшиться — но база получит больше одновременной работы и начнёт отвечать ещё медленнее.

Разбор относится к Drupal 10 и 11: конкретные значения настроек и поведение модулей сверяйте с версией вашего проекта. Это не универсальная инструкция по настройке лимитов. Цель — связать симптомы с измерениями и найти ограничивающий участок до того, как менять конфигурацию.

При росте нагрузки важно не то, сколько запросов сайт принял, а где они ждут и что удерживает ресурсы, пока ждут.

Как проходит запрос и где образуется очередь

Типичный запрос проходит через веб-сервер и PHP-FPM, затем Drupal загружает нужные данные — часто из базы или кеша — и формирует ответ. На каждом участке может накопиться очередь. Если PHP-FPM занят, новые запросы ждут свободного рабочего процесса. Если процессы заняты долгими SQL-запросами, увеличение их числа может усилить конкуренцию за базу. Если страница не кешируется, Drupal повторяет работу даже для одинаковых обращений.

Кеш в Drupal — не одна кнопка, а несколько уровней. Внутренний кеш может сократить повторную работу приложения; кеш рендеринга хранит результат сборки части страницы; кеш страниц помогает повторно отдавать готовый ответ при подходящих условиях. Для анонимных и авторизованных посетителей условия часто различаются: персонализация, права доступа и контекст пользователя могут сделать общий ответ небезопасным или просто невозможным.

Контекст кеша¹ описывает, от каких характеристик зависит корректность кешированного результата. Например, если вывод меняется для разных языков или ролей, кеш должен учитывать это различие. Ошибка в таких условиях может не только снизить попадания в кеш, но и показать посетителю неподходящий контент.

Снимите данные до изменения настроек

Сравнивайте одинаковые сценарии: один и тот же URL, тип пользователя, объём данных и профиль запросов. Запишите время ответа, долю ошибок, загрузку CPU и памяти, занятость PHP-FPM и состояние базы данных. Важно смотреть на динамику во время теста и после него: среднее время может скрыть редкие, но болезненные задержки.

• Если растёт очередь PHP-FPM, проверьте число занятых процессов и длительность запросов. Нехватка рабочих процессов — симптом; выясните, почему они долго не освобождаются.
• Если база показывает долгие запросы, сопоставьте их с конкретными страницами и действиями. Ищите повторяющиеся выборки, большие объёмы чтения и запросы, которые появляются только при фильтрации или сортировке.
• Если CPU приложения загружен, а база не перегружена, проверьте, не выполняется ли повторная сборка одних и тех же данных и разметки. Смотрите, какие ответы попадают в кеш, а какие каждый раз обходят его.
• Если ошибки начинаются при росте числа посетителей, фиксируйте момент появления ошибок и очередей, а не только их итоговое количество. Так проще связать отказ с конкретным пределом ресурса.

Для воспроизводимого теста задайте профиль нагрузки и постепенно увеличивайте параллельность. Не начинайте с предельного теста на рабочем сайте: нагрузка может ухудшить доступность для реальных посетителей. На тестовом окружении проверьте, что там сопоставимы версия Drupal, данные, модули, конфигурация PHP и база. Иначе результат покажет поведение стенда, а не боевого проекта.

Три направления диагностики

Кеш — не лекарство от любой медленной страницы

Сначала выясните, почему ответ не переиспользуется. Страница может зависеть от пользователя, ролей, языка, параметров запроса или другого контекста. Если менять кеширование без проверки этих зависимостей, можно получить устаревший вывод или ошибку в доступе к данным. Если ответ должен быть персональным, ищите экономию в повторно используемых фрагментах и более эффективной загрузке данных, а не пытайтесь сделать весь ответ общим.

Проверьте сценарии, которые легко упустить: первая загрузка после очистки кеша, массовый выход кешированных данных из срока действия, страницы с фильтрами и страницы авторизованных пользователей. Сайт может выдерживать обычный поток, но проседать, когда много запросов одновременно запускают одинаковую дорогую работу.

Не увеличивайте PHP-FPM вслепую

Число процессов PHP-FPM ограничивает параллельную обработку PHP-запросов. Если увеличить этот предел, не проверив доступную память и способность базы принять дополнительные запросы, система может перейти от очереди PHP к перегрузке другого ресурса. Смотрите на потребление памяти на процесс, занятость пула и задержки базы во время одного и того же теста. Точные параметры пула зависят от конфигурации PHP-FPM, ОС и ресурсов сервера; подставлять одно «правильное» число для всех сайтов нельзя.

Аналогично, увеличение серверных ресурсов может отодвинуть предел, но не исправить причину. Если каждый запрос читает лишние данные или ждёт внешний сервис, более мощная машина даст запас, но не обязательно уберёт задержки. После любого изменения повторяйте тот же тест и фиксируйте, какой показатель изменился.

Граничные случаи: где оптимизация ломается

• Очистка кеша. После неё приложение должно заново сформировать кешированные данные. Если множество посетителей одновременно запрашивают одни и те же страницы, нагрузка может кратковременно вырасти. Проверяйте поведение именно в этом сценарии.
• Персонализация. Персональные блоки или различия по ролям могут менять условия повторного использования ответа. Не убирайте зависимость от пользователя ради красивого показателя кеш-хитов.
• Фоновые задачи. Импорт, рассылка или пересчёт данных конкурируют за процессор, память и базу с пользовательскими запросами. Сравните показатели при включённых и выключенных фоновых операциях.
• Внешние сервисы. Медленный API или файловое хранилище может удерживать PHP-процесс дольше обычного. Проверьте длительность обращений к зависимостям и поведение при их задержке.
• Разный стенд и продакшен. Маленькая тестовая база, другой набор модулей или отключённое кеширование меняют результат. Перед выводами перечислите отличия окружений.

Если после изменения сайт стал быстрее только в среднем, но выросли ошибки или ухудшились самые медленные ответы, решение нельзя считать успешным. Сопоставляйте задержки, ошибки и потребление ресурсов вместе. Для каждого изменения оставляйте возможность отката и фиксируйте исходные настройки.

Что делать дальше

Составьте короткий план наблюдения: выберите несколько критичных страниц, определите сценарии анонимного и авторизованного пользователя и снимите показатели до изменения конфигурации. Затем меняйте по одному фактору — например, условия кеширования или лимит PHP-FPM — и повторяйте тот же профиль нагрузки.

После диагностики настройте мониторинг очереди PHP-FPM, времени ответа, ошибок и долгих запросов к базе. Отдельно проверьте поведение при очистке кеша и запуске фоновых задач. Если ограничение стабильно связано с базой или внешней зависимостью, переходите к её разбору: настройка Drupal не устранит предел, который находится за пределами приложения.

¹ Контекст кеша — характеристика, от которой зависит вариант результата, пригодный для повторного использования, например язык или роль пользователя. В Drupal контекст нужен, чтобы кеш не смешивал ответы, которые должны различаться.