Подготовка PHP-приложения к пикам трафика — это не умножение обычного числа посещений на произвольный коэффициент. Необходимая ёмкость зависит от количества одновременных запросов, времени их выполнения и выполняемой работы: кэшированная страница и операция, обращающаяся к нескольким внешним сервисам, потребляют разные ресурсы.
Операционная цель — понять, какой компонент ограничивает работу сервиса при репрезентативной нагрузке, какой запас ёмкости доступен и что делать, когда он исчерпан. Тестирование даёт основания для принятия решений, но не гарантирует универсальную ёмкость: результат зависит от кода, инфраструктуры, данных и реального сценария использования.
Оценивайте нагрузку по параллельному выполнению запросов и типу операции
Дневного или месячного объёма недостаточно для расчёта ёмкости. Приложение может получать много посещений, равномерно распределённых по нескольким часам, и работать с запасом либо концентрировать запросы в течение нескольких минут и перегружаться. Чтобы оценить нагрузку, отслеживайте интенсивность поступления запросов, длительность запросов и долю одновременно выполняющихся операций.
В качестве ориентира: если интенсивность поступления не меняется, а длительность запросов растёт, больше запросов остаются активными одновременно. Поэтому медленная зависимость может увеличить число одновременно выполняющихся запросов, даже если входящий трафик не изменился. Нагрузка также может быть неравномерной: рекламная кампания способна резко увеличить число просмотров страниц товаров и поисковых запросов, а закрытие периода — сконцентрировать аутентификации, экспорт данных или операции записи.
Начните с определения маршрутов и операций, влияющих на бизнес-цели. Включите, например, публичную навигацию, поиск, вход в систему, создание заказов и важные административные задачи. Разделяйте чтение и запись, кэшируемые и некэшируемые запросы, синхронные запросы и задачи, которые можно обрабатывать в очереди. Не позволяйте общему среднему значению скрывать медленный или критически важный маршрут.
Создайте репрезентативный и безопасный тест
Определите один или несколько сценариев на основе доступной телеметрии, журналов доступа и календаря известных событий. Задокументируйте долю запросов для каждой операции, изменение интенсивности поступления и длительность каждой фазы. Целесообразно проверить устойчивую нагрузку и резкий рост: они показывают разные варианты поведения — постепенное исчерпание ресурсов и резкую реакцию на пик.
Тест следует запускать в среде, которая достаточно точно отражает конфигурацию production, чтобы результаты были полезны. Проверьте различия в количестве процессов, лимитах подключений, кэшах, объёме данных и зависимостях. Если тест выполняется на изолированной машине с небольшими таблицами, это не доказывает, как поведёт себя production. Не создавайте нагрузку на реальных пользователей без чёткого плана и явного разрешения.
Заложите защиту данных в сценарий с самого начала. Используйте синтетические или анонимизированные данные, отдельные учётные данные и минимально необходимые разрешения; не копируйте персональные данные в инструменты нагрузочного тестирования без надлежащих правовых оснований и мер контроля. Не допускайте, чтобы тесты отправляли электронные письма, списывали платежи или создавали необратимые последствия. Для внешних операций используйте тестовые среды или контролируемые заглушки, помня, что заглушка не обязательно воспроизводит задержки и ограничения реального сервиса.
Одновременно измеряйте задержку, ошибки и насыщение
Регистрируйте задержку для каждого маршрута и отслеживайте перцентили, например p50, p95 и p99. Среднее значение может оставаться стабильным, хотя часть запросов становится очень медленной; перцентили лучше показывают этот хвост распределения. Также измеряйте частоту ошибок, время ожидания и количество запросов, обработанных за единицу времени. Тест, который создаёт множество запросов, но также приводит к ошибкам, не подтверждает наличие полезной ёмкости.
Сопоставляйте эти показатели с ресурсами и очередями. В PHP отслеживайте занятость и очередь процессов, обрабатывающих запросы, а также CPU, память и перезапуски. Если используется PHP-FPM, проверяйте конфигурацию и метрики его процессов и веб-сервера; доступные названия показателей зависят от используемой инструментации. Для базы данных измеряйте активные подключения, время ожидания подключения, медленные запросы, блокировки и загрузку CPU или диска. Также отслеживайте кэши, очереди и внешние зависимости.
Устанавливайте пороговые значения, привязанные к пользовательскому опыту и операциям, а не только к загрузке CPU. Например, для маршрута покупки можно согласовать максимальную задержку и частоту ошибок, тогда как для некритичного экспорта допустимы ожидание или асинхронная обработка. Убедитесь, что часы и окна наблюдения сопоставимы и что можно связать рост задержки с компонентом, который достиг насыщения.
Найдите первое узкое место, прежде чем масштабировать
Ищите первый показатель, который ухудшается при постепенном увеличении нагрузки. Если растёт очередь веб-процессов, а загрузка CPU PHP остаётся высокой, причиной может быть дорогая обработка каждого запроса или нехватка доступных процессов. Если процессы ждут подключений, но у базы данных есть запас ресурсов, проверьте лимит пула или настройки подключений. Если база данных демонстрирует медленные запросы, блокировки или насыщение, добавление PHP-процессов может увеличить нагрузку и усугубить проблему.
Внешние зависимости также могут надолго занимать процессы. Проверяйте время установления соединения и ответа, лимиты частоты запросов и поведение при ошибках. Слишком длительный тайм-аут надолго занимает ресурсы; неограниченные повторы могут многократно увеличить нагрузку. Задавайте ограниченные тайм-ауты и избирательную политику повторов с постепенной задержкой, где это уместно, и не повторяйте автоматически неидемпотентные операции без защиты.
Отличайте нехватку ёмкости от неэффективности. Запрос, обрабатывающий слишком много строк, повторные вызовы одного и того же сервиса или избыточные вычисления останутся затратными и после добавления серверов. Профилируйте репрезентативные маршруты и сокращайте объём работы на запрос: оптимизируйте запросы и индексы на основе измерений, ограничивайте результаты, устраняйте ненужные вызовы и используйте кэш, если это допускают требования к согласованности и конфиденциальности. Затем повторите тест, чтобы убедиться, что улучшение сохраняется под нагрузкой.
Действуйте по порядку и планируйте контролируемое снижение функциональности
Сначала снизьте стоимость обработки каждого запроса и исправьте запросы или зависимости, которые ограничивают работу. Затем проверьте лимиты параллельного выполнения запросов, веб-процессы и пулы подключений. Увеличение числа процессов может повысить параллелизм, пока не будут исчерпаны ресурсы CPU, память или база данных; настройка большего числа подключений, чем способна обслужить база данных, лишь перемещает очередь. Меняйте по одной переменной и повторяйте измерения.
Вертикальное масштабирование — увеличение ресурсов одного экземпляра — может быть простым решением, если компонент допускает рост и нет структурного ограничения. Для горизонтального масштабирования — добавления экземпляров — необходимо, чтобы deployment, сессии, файлы, задачи и база данных поддерживали такое распределение. Проверьте балансировку нагрузки, общее или внешнее хранилище, если оно необходимо, состояние экземпляров и общие лимиты, например подключения к базе данных. Ни один из этих вариантов сам по себе не исправит неэффективный запрос.
Определите, что нужно сохранить при нехватке ёмкости. Расставьте приоритеты для аутентификации, основных операций или подтверждений транзакций в соответствии с особенностями продукта; откладывайте отчёты, ограничивайте ресурсоёмкий поиск или временно отключайте второстепенные функции. Используйте очереди для задач, которые можно выполнить позже, и сообщайте пользователю об их состоянии. Явно применяйте лимиты частоты запросов или ответы о перегрузке, предусмотрев разумные механизмы повторов. Контролируемое снижение функциональности не должно приводить к потере подтверждённых операций и должно предлагать понятную альтернативу, а не возвращать фиктивный успех.
Чтобы превратить результаты тестирования в операционное решение, ведите журнал со сценарием, конфигурацией, результатами по маршрутам, первым обнаруженным ограничением, внесёнными изменениями и критериями приёмки. Повторяйте тест после изменений кода, инфраструктуры, данных или значимых зависимостей. Перед ожидаемым пиком проверьте оповещения, доступную ёмкость, процедуры отката и ответственных за принятие решений.
Контрольный список перед пиком
- Сценарий: отражает правдоподобные маршруты, пропорции, интенсивность и длительность; включает резкий рост и устойчивую нагрузку.
- Безопасность: использует подходящие данные и учётные данные, исключает нежелательные реальные последствия и контролирует целевую систему тестирования.
- Наблюдаемость: сопоставляет задержку p95/p99 и ошибки с количеством запросов, обработанных за единицу времени, а также с процессами PHP, базой данных, кэшем и внешними зависимостями.
- Диагностика: определяет первое ограничение и подтверждает, вызвано ли оно насыщением, запросами, параллельным выполнением операций или ожиданием внешних систем.
- Изменения: меняет по одной переменной за раз, сравнивает результаты и проверяет, что насыщение не перемещается на другой уровень.
- Отказоустойчивость: определяет лимиты, приоритеты, сценарии снижения функциональности, порядок информирования и восстановление без потери подтверждённых операций.
- Повторное тестирование: устанавливает критерии приёмки и повторяет тесты после значимых изменений и перед предсказуемыми событиями.
Точный расчёт ёмкости означает понимание того, как приложение ведёт себя в конкретных сценариях, и принятие решений с запасом, а не погоню за абстрактным числом пользователей. Измерения показывают, куда направить усилия: на оптимизацию, настройку параллельного выполнения запросов, увеличение ёмкости или политику снижения функциональности, которая сохраняет полезность основных функций.
