Skip to content
Все статьи
Стандарты и методика

Как мы тестируем веб-порталы под нагрузкой: сценарии и p99

Alexander Zemskov 4 мин чтения
Как мы тестируем веб-порталы под нагрузкой: сценарии и p99

Нагрузочный тест портала часто сводится к одному URL и одной цифре: главная страница отвечает, скажем, на 8000 запросов в секунду, значит, сайт готов. Потом в 9:00 несколько тысяч человек разом входят, ищут и отправляют формы, и сервису авторизации не хватает соединений с базой. Главная все это время отдавалась из кэша. Мы нагружаем портал так, как с ним работают пользователи, и ищем слой, который сдается первым.

Стенд

Портал остается там, где работает: в вашем облачном тенанте, в вашем ЦОД или в виде staging-копии на гипервизоре стенда. Нагрузку дают L4-7 движки стенда, коммерческие генераторы и генератор, который мы делаем сами, через реальное облачное подключение или выделенный канал. У каждого эмулированного пользователя своя тестовая учетная запись, свой адрес источника и своя TLS-сессия, поэтому кэши, привязка сессий и rate limit ведут себя так же, как с живыми людьми. Порталы вместе с инфраструктурой перед ними – один из классов на странице облако и NFV.

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

Что проверяем

  • Ramp-up: от 1000 до 200 000 одновременных пользователей ступенями, удержание на каждой и ступень, на которой портал выходит из согласованного порога
  • Запросы в секунду до первой ошибки: HTTP 5xx, таймауты, отказы в соединении, затем доля ошибок на каждой ступени
  • Время ответа по транзакциям: p50, p95 и p99 для входа, поиска, формы и каждого вызова API
  • Проверка содержимого: код 200 со страницей ошибки внутри считается отказом
  • TLS: handshake в секунду там, где терминируется TLS (балансировщик, WAF или приложение), во время утреннего наплыва
  • Слой, который упирается первым: соединения на балансировщике, задержка WAF с полным набором правил, пулы приложения, запросы и блокировки в базе
  • Soak: от 2 до 24 часов на постоянной нагрузке, последний час против первого
  • Облако и on-prem: сколько длится автомасштабирование и что в это время с p99, одни и те же сценарии на обеих площадках, счет за облако за прогон

Критерии прохождения согласуем до прогона. Ramp и soak идут по методике наших нагрузочных тестов, а WAF или балансировщик можно отдельно измерить как класс устройств.

Что обычно ломается

Чаще всего база данных. Пример с круглыми цифрами: приложение масштабируется с 4 до 12 экземпляров, у каждого пул на 50 соединений, а база принимает 300. Примерно на 6000 пользователей новые экземпляры ждут соединений, p99 входа растет с 0,8 до 9 секунд, а CPU веб-слоя остается зеленым. Новые экземпляры только просят еще соединений.

Второй случай: автомасштабирование, которое реагирует поздно. Новый экземпляр появляется после 5 минут выше 70% CPU и еще 3 минуты прогревается, а утренний наплыв длится 10. Из этих 10 минут 8 портал работает на мощности, которая была у него в 8:59.

Третий: путь перед порталом. Привязка сессий по адресу источника отправляет целый офис за одним NAT на один сервер. WAF добавляет 40 мс на p99 (пример) и упирается в CPU раньше приложения. TLS терминируется на балансировщике, рассчитанном на просмотры страниц, и утренний вход превращается в шторм handshake. 3 машины, которые грузят один URL, ничего из этого не покажут.

Что в отчете

Таблицу на каждую ступень нагрузки: пользователи, запросы в секунду, p50, p95 и p99 по транзакциям, ошибки по типам. Слой, который уперся первым, с его счетчиками в этот момент. Цифры TLS, кривую soak, хронологию автомасштабирования и стоимость облачного прогона. Сценарии и настройки генератора лежат в отчете, поэтому прогон после исправления повторяет тот же тест.

С чего начать

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

Автор

Alexander Zemskov

Эксперт по тестированию сетей и безопасности, продажи (19+ лет) | Performance & Load Testing | IXIA | Spirent | Keysight | Xena | Xinertel и другое

Блог

Читайте также