Нагрузочное тестирование

Не секрет, что я работаю над сайтами с большой нагрузкой, а в таких случаях конечно же нужно тестировать сайты, чтобы убедится, что они выдержат нагрузку. 

Сегодня прочитал мнение, что нагрузочное тестирование нужно гнать на CI сервере. Если честно, то мне сложно это представить. CI сервер должен взять изменения, откомпилировать и запустить тесты. На больших проектах тесты могут выполняться достаточно долго, у меня они гнались два часа. Если после этого еще и гнать нагрузочное тестирование, то это отнимет слишком уж много времени. 

Ну не знаю, на мой взгляд юнит тесты на много важнее. Нагрузочное тестирование может занимать часы, ведь нужно подержать каждую страницу хотя бы минут 10 под нагрузкой. Две минуты могут ничего не дать, и вы не увидите результат. Такие ошибки, как не закрытое соединение с базой данных, не закрытое соединение с сервисом, отсутствующий индекс могут серьезно проявится только минут через 10 – 15 нагрузки, а могут даже через пол часа.

У меня был случай, когда забыли закрыть соединение с сервисом. Сайт работал даже под нагрузкой в 1,000 одновременных пользователей согласно Google Analytics в течении часу без проблем и только потом падал. Перезапуск пулов приложений помогал на час, и потом сайт снова падал. И так пока не вычислили метод, где сервис оставался не закрытым. 

Даже если выбрать штук 10 страниц и тестировать их под нагрузкой, то это будет долго. Я бы не вешал это на CI сервер, потому что он должен работать чаще, лучше как минимум каждые два часа брать изменения с репозитория и гнать тесты, ведь чем раньше будет найдена проблема в коде, тем лучше. 

Для тестов производительности лучше отдельный сервер. Это может быть второй CI сервер, который будет забирать изменения раз в день, но его цель будет не гнать юнит тесты после компиляции, а проверять производительность сайта. 

Если проверять производительность каждый день, то можно выловить изменения, которые негативно влияют на скорость и это плюс. Но вот только изменения в уже отлаженный код происходят не так часто. В моей практике постоянно идет новая разработка, добавляются новые фишки. А вот новые фишки обычно вылетают в тех случаях, когда есть достаточно данных. Просто нагружать сервер однообразными тестами не поможет выявить проблему скорости, тут нужна специальная работа, нужно накидать данные в новые таблицы, причем данные максимально близкие к тому, что будет в жизни. 

Так что даже раз в неделю прогонять тесты в реальной жизни вполне достаточно. Если вы работаете в Agile, то достаточно делать это в конце каждого спринта. Но этим должен заниматься специальный персонал, который будет не просто гнать уже подготовленные в прошлом сценарии, а будет смотреть на изменения, нагружать базу данными и следить за результатами. 

---

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым

---