Об ИТ из Канады

Блог Михаила Флёнова - программист, блогер, автор нескольких скандальных книг какими-то глазами...

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

2017-05-26 06:09:16 / Программирование

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

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

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

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

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

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

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

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


Понравилась статья?

Комментарии

Storm

У нас было так: у CI сервера куча слейвов с развернутыми окружениями (виртуалки), в зависимости от бранча (юзаем гит флоу) гонится разный набор тестов, девелоперские бранчи гоняют только юниты и девелоперы получают максимально быстрый фидбек, релизный бранч гоняет интеграционные, мастер прогоняет всё потому что он должен быть всегда стабильный, да на мастере полный прогон тестов занимает несколько часов, но и вероятность ошибки там мала, так как добравшись мастера код уже становится достаточно стабильным.

2017-05-26 09:52:40

Оставить комментарий


Умеешь пользоваться BB кодами? Прекрасно, здесь можно использовать [quote] для цитирования, а так же [b] и [i]. Остальные коды пока использовать запрещено. Я думаю по поводу их использования. В комментариях нельзя выяснять крутость каких-либо продуктов, нужно уважать собеседников и не грубить и нельзя ничего додумывать (читайте мои посты внимательно). Нарушение этих простых правил ведет к удалению комментариев без предупреждения.

О блоге

Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю

Внимание!

А ты уже читал мою последнюю книгу о больших сайтах и приложениях? Узнай, что это такое здесь

Обратная связь

Без проблем вступаю в неразборчивые разговоры по e-mail. Стараюсь отвечать на письма всех читателей вне зависимости от страны проживания, вероисповидания на русском или английском языке.

Пишите мне