Нагрузочный тест портала часто сводится к одному 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 сценариев, на которых держится ваш бизнес, и нагрузку, которую ждете в пиковый час. Мы ответим черновиком плана: сценарии, ступени нагрузки, как соберем стенд и в какие сроки. Отчет остается у вас, его можно показать разработчику или хостинг-провайдеру. Напишите нам или посмотрите, что еще умеет стенд.