.jpg)
Нагрузочное тестирование Интернет-проекта
Успешные кейсы
К нам обратился крупный образовательный акселиратор "Арбион" со следующей проблемой.
Клиенту другой разработчик собрал новый сайт на Wordpress. Чтобы проверить, какую нагрузку он выдерживает, направили часть трафика со старого сайта на новый. Сайт «лег». Перед клиентом встал вопрос — «чинить» новый сайт или «хоронить», и разработать ещё один на фреймворке.
Мы предложили провести нагрузочное тестирование интернет-проекта и технический аудит сайта — так как была вероятность, что проблему получится решить доработкой компонентов и настройкой серверного окружения.
Постановка целей и задач
Мы хотели проверить максимальную производительность сайта — чтобы клиент понял, что можно получить на текущем оборудовании, а мы увидели перспективы масштабирования проекта в случае замены сервера.
Цель теста: выяснить предельное количество пользователей в секунду, которое может выдержать текущая конфигурация «сервер плюс сайт» и определить самые «тяжелые» страницы для последующей оптимизации.
Цель теста: выяснить предельное количество пользователей в секунду, которое может выдержать текущая конфигурация «сервер плюс сайт» и определить самые «тяжелые» страницы для последующей оптимизации.
Определение условий и инструментов нагрузочного тестирования
Для прогрева кеша использовали статичную нагрузку. В качестве инструмента нагрузочного тестирования — Яндекс Танк с модулем Phantom. Phantom отличается высокой производительностью, но не позволяет генерировать POST-запросы — мы не можем проверить сценарии отправки отзывов, авторизации на сайте. Поэтому мы оценивали количество запросов в секунду, которое может выдержать сайт.
Подготовка к нагрузочному тестированию
Важно грамотно определить сценарии нагрузочного тестирования. Не всегда понятно, на что более всего тратятся серверные ресурсы — куда направлять ботов. Направив нагрузку не на проблемные места сайта, можно получить хорошие, но ложные результаты. Поэтому нужно как можно точнее смоделировать действия пользователей.
Чтобы определить сценарии, мы выгрузили список страниц сайта и сформировали перечень из примерно 1000 страниц с примерным соотношением.
Чтобы определить сценарии, мы выгрузили список страниц сайта и сформировали перечень из примерно 1000 страниц с примерным соотношением.
Определение предела теста
Были выставлены лимиты, при достижении любого из которых стресс-тест автоматически останавливается:
- time(3s,20s) — если среднее время ответа более 3 секунд в течение 20 секунд;
- http(5xx,100%,10s) — если в течение 10 секунд 100% обращений выдают 5xx ошибки;
- net(xx,100%,5s) — если в течение 5 секунд 100% получаем ошибки сети, такие как 104 — Connection reset by peer и 110 — Connection timed out.
Запуск и анализ результатов нагрузочного тестирования
Чтобы получить корректные значения, стресс-тест сайта нужно выполнять в несколько этапов.
Этапы тестирования
- Подготовка конфигурации Яндекс Танк.
- Пробный "обстрел" для проверки конфигурации, примерных лимитов и шагов наращивания интенсивности, выявление ошибок конфигурации тестового задания.
- Непосредственно тестирование — его лучше выполнить несколько раз.
Проведение тестов и анализ результатов нагрузочного тестирования
Мы провели несколько тестов и получили результаты, которыми поделимся ниже.
RPS (request per second) — число запросов в секунду на страницы сайта, которые производили при нагрузочном тестировании. Показывает примерное количество запросов, после которого был прерван тест — либо из-за отсутствия ответа по сети, либо из-за ошибок в HTTP запросах.
RPS (request per second) — число запросов в секунду на страницы сайта, которые производили при нагрузочном тестировании. Показывает примерное количество запросов, после которого был прерван тест — либо из-за отсутствия ответа по сети, либо из-за ошибок в HTTP запросах.
Тест 1
Условия: запущен тест примерно на 1000 страниц, отсортированных по типам и по алфавиту. Кэш на сайте не сбрасывали.
RPS=256. В этот раз сайт также выдержал нагрузку, и нагрузка на сервер составила не более 30%. Нагрузка на базу данных была мизерной. LoadAverage не превышал трех. Тест прервался по причине сетевой недоступности из-за повышенной нагрузки на канал связи.
RPS=256. В этот раз сайт также выдержал нагрузку, и нагрузка на сервер составила не более 30%. Нагрузка на базу данных была мизерной. LoadAverage не превышал трех. Тест прервался по причине сетевой недоступности из-за повышенной нагрузки на канал связи.
