Подробно
Нагрузочное тестирование сайта показывает, что случится, когда на него одновременно придут сотни или тысячи людей: после рассылки, рекламы, распродажи или публикации в СМИ. Мы воспроизводим поведение реальных посетителей, постепенно наращиваем нагрузку и смотрим, где система начинает тормозить и что ломается первым. По итогу вы получаете отчет: какую нагрузку проект держит сейчас, что мешает держать больше и что исправить в первую очередь. Как устроены виды тестов и метрики, подробно разобрали в статье что такое нагрузочное тестирование.
Когда нужно нагрузочное тестирование
Проверять нагрузку стоит до события, а не после жалоб клиентов. Обычные поводы:
- распродажа, рекламная кампания или рассылка по большой базе;
- запуск нового продукта или переезд на другой сервер;
- крупное обновление, после которого сайт стал отвечать медленнее;
- рост числа пользователей, когда непонятно, сколько еще выдержит текущий сервер;
- выпуск мобильного приложения, если ожидается много установок в первые дни.
Если сайт уже падал под нагрузкой, тест помогает найти причину. Часто это не нехватка мощности сервера, а один тяжелый запрос к базе или внешний сервис, который отвечает медленно и держит все остальные запросы.
Нагрузочное тестирование сайта
Сначала выбираем сценарии, которые создают основную нагрузку: каталог, поиск, карточка товара, корзина, оформление заказа, вход в личный кабинет. Долю каждого сценария берем из вашей аналитики, чтобы тестовый трафик был похож на настоящий. Если большинство посетителей только смотрит каталог, а заказывает малая часть, тест повторяет эту пропорцию.
Нагрузку подаем ступенями и на каждой ступени фиксируем время ответа, долю ошибок, загрузку процессора, памяти и базы данных. Так видно, на какой ступени система перестает укладываться в ваши требования и какой компонент сдается первым.
Тест проводим на копии рабочего сервера. Если копию поднять нельзя, работаем на рабочем сервере в ночное окно по согласованию с вами. Платежи и письма клиентам на время теста отключаем или переводим в тестовый режим, чтобы виртуальные пользователи не создали настоящие заказы.
Нагрузочное тестирование API и сервера приложения
У мобильного приложения нагрузку держит не телефон, а сервер. Поэтому тестируем API: вход, ленту, поиск, оформление заказа, отправку push-уведомлений. Такой тест точнее браузерного и позволяет создать большую нагрузку меньшими ресурсами. Отдельно проверяем пиковый сценарий: рассылку push всем пользователям, после которой тысячи человек одновременно открывают приложение.
Какие тесты проводим
- тест на ожидаемой нагрузке: система держит обычный трафик с нужным временем ответа;
- стресс-тест: повышаем нагрузку, пока система не начнет отказывать, и смотрим, как она восстанавливается;
- пиковый тест: резкий всплеск трафика, как после рассылки или рекламы;
- тест стабильности: обычная нагрузка несколько часов подряд, чтобы поймать утечки памяти и накопление соединений с базой.
Набор тестов выбираем под задачу. Интернет-магазину перед распродажей обычно хватает первых трех, сервису, который работает круглосуточно, нужен и тест стабильности.
Что вы получаете после теста
Отчет с графиками времени ответа и ошибок по каждой ступени нагрузки, предел, до которого система укладывается в ваши требования, и список узких мест. По каждому узкому месту пишем причину и способ исправления: медленный запрос к базе, нехватка памяти, отсутствие кэша, ограничение внешнего сервиса. Если исправления делаем мы, после них повторяем тест на тех же сценариях и показываем разницу.
Бывает, что тест упирается не в отдельные запросы, а в устройство системы. Тогда предлагаем план переработки архитектуры, этим занимается направление разработки высоконагруженных систем.
