Тестирование производительности

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

Это зонтичное понятие. Внутри него несколько видов проверок с разными целями: нагрузочное тестирование проверяет ожидаемый трафик, стресс-тестирование ищет точку отказа, тест на выносливость гоняет систему часами, чтобы поймать утечки памяти, а пиковый — моделирует резкий всплеск, например после рассылки.

Что измеряют

• Время ответа — не среднее, а перцентили: p95 показывает, сколько ждут 5% самых невезучих посетителей.
• Пропускную способность — сколько запросов в секунду сервер обрабатывает без роста ошибок.
• Долю ошибок: коды 5xx, таймауты, обрывы соединений.
• Потребление ресурсов: процессор, память, число соединений с базой, длина очередей.

Пример быстрой проверки

Самый простой инструмент — ApacheBench. Команда отправит 1000 запросов на главную страницу, по 50 одновременно, и выведет время ответа и число запросов в секунду:

ab -n 1000 -c 50 https://example.ru/

Для сценариев посложнее — вход в личный кабинет, поиск, оформление заказа — используют k6, JMeter, Gatling или Locust. Они умеют повторять цепочку действий пользователя и плавно наращивать нагрузку.

Как не получить ложный результат

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