Drupal под нагрузкой: где искать узкие места

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

Сначала отделите медленный ответ от медленного сайта

Измеряйте не только среднее время ответа. Оно скрывает редкие, но болезненные задержки. За один и тот же интервал соберите p50, p95 и p99 времени ответа, долю ошибок, число запросов в секунду и состояние зависимостей. Сравнивайте один и тот же маршрут и сценарий: анонимную главную, страницу авторизованного пользователя и, если он важен, операцию записи.

Drupal 10 и 11 используют кеширование на нескольких уровнях, поэтому сначала проверьте, какой путь проходит запрос. Ответ, уже сохранённый внешним кешем, не проверяет производительность PHP и базы данных. Ответ из кеша Drupal тоже может быть существенно дешевле холодной сборки страницы. Не смешивайте эти результаты в одном графике.

• Зафиксируйте версию Drupal core, PHP, СУБД, веб-сервера и настройки кеширующего прокси.
• Повторите тест отдельно для анонимного и авторизованного трафика.
• Запишите долю попаданий в кеш и число промахов, если эти метрики доступны.
• Сопоставьте всплески задержки с загрузкой CPU, памятью, диском, числом PHP-FPM-процессов и ожиданием базы.

Так вы получите не «Drupal медленный», а наблюдаемую картину: например, p95 растёт одновременно с очередью PHP-FPM, либо задержка базы увеличивается при прежней загрузке приложения. Именно эта разница задаёт следующий шаг.

Где Drupal чаще всего теряет время

Кеш не попадает или часто сбрасывается

Для анонимного трафика ответ может обслуживать кеш на уровне CDN или reverse proxy. Внутри Drupal кеширование данных и собранных фрагментов страницы сокращает повторную работу. Если каждый запрос считается уникальным из-за контекста кеша, вариативности по пользователю или некорректных заголовков, число попаданий падает. Если кеш часто инвалидируется, прогрев не успевает окупиться.

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

PHP-FPM ограничивает параллельность

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

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

База данных отвечает медленно или получает слишком много работы

Причина бывает не в «слабой базе», а в конкретном запросе, который читает много строк, ждёт блокировку или повторяется слишком часто. В Drupal это может быть связано с тяжёлой выдачей, сложным представлением данных, кастомным кодом или модулем. Профилируйте запросы на реальном сценарии и сопоставляйте их с логами СУБД. Не добавляйте индекс вслепую: индекс ускоряет некоторые чтения, но занимает место и может замедлить запись.

Тяжёлый рендеринг и работа модулей

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

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

Симптомы и следующий замер

Как измерять изменения без самообмана

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

1. Выберите сценарий, который воспроизводит жалобу: маршрут, тип пользователя и последовательность действий.
2. Прогоните его несколько раз с одинаковыми условиями; отдельно пометьте холодный и прогретый кеш.
3. Соберите задержки p50, p95 и p99, пропускную способность и ошибки вместе с метриками PHP-FPM и СУБД.
4. Измените один фактор и повторите прогон на том же стенде.
5. Проверьте, что улучшение не ухудшило запись, персонализированные страницы или корректность ответа.

Публичных универсальных цифр «нормальной скорости Drupal» нет: сайт-каталог и портал с персонализацией нельзя честно сравнить без одинакового сценария и инфраструктуры. Если нет трассировки запросов, начните с добавления наблюдаемости, а не с покупки более крупного сервера.

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

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

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

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

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

Для Drupal 10 и 11 начните с одного проблемного маршрута и разделите его на попадание в кеш, выполнение PHP, запросы к базе и внешние зависимости. Зафиксируйте исходные метрики, затем меняйте по одному фактору. В проде продолжайте смотреть на p95 и p99, долю кеш-попаданий, очередь PHP-FPM и задержки СУБД: именно их сочетание покажет, вернулось ли узкое место после следующего роста трафика.