Pull to refresh

Comments 7

Удивительно, что ни разу не упомянули gatling.io в инструментах. Мне казалось он популярен.
Наверняка, я видел далеко не все нагрузочные тесты в Netcracker, но Gatling наблюдать не приходилось. Полагаю, дело в том, что, в подавляющем большинстве случаев, нам миллионы запросов в секунду не нужны. В JMeter'е более-менее пишутся сложные тесты (зайти туда-то, нажать такую-то кнопку и т.п.), и порог вхождения невелик.

Он популярен у джавистов, потому что тесты можно писать в той же парадигме, что и сам код. В том смысле, что тесты – это тоже код. Не слышал, чтобы кто-то его использовал в Яндексе, хотя мне он показался интересным. В том числе и потому что он на Akka, а значит, не плодит треды под каждый запрос, в отличие от JMeter. Даже думали прикрутить gatling к Яндекс.Танку, но пока нет желающих им стрелять.


У нас сейчас развиваются нагрузочные сценарии на Python – в Яндекс.Танке для этого есть пушка BFG.

Он популярен у джавистов

Не соглашусь, он все же на scala, а она хоть и близка к java, но всё же совсем другая кухня

тесты можно писать в той же парадигме, что и сам код. В том смысле, что тесты – это тоже код

Тоже сложно согласиться, в нём больше всего выигрывает хорошая визуализация результатов, возможность scaling`а и легкость в разворачивании(хотя порог вхождения достаточно высокий).
Кроме того, исходя из личного опыта тесты не то, чтобы код, скорее артефакт, которым возможно прийдется поделиться с product owner`ом. Так что если в этом понимании — тогда согласен, иначе нет(хотя возможно в каких то моделях SDLC ваше утверждение и справедливо).

Ну платформа все равно та же – библиотеки можно те же использовать, можно переиспользовать для генерации нагрузки части своего проекта, если он на java. Язык это уже вторично.
Я в первую очередь сказал про код, а не про визуализацию, потому что с точки зрения визуализации, у нас не хуже.
Про scaling и легкость в разворачивании ничего не могу сказать, потому что не пробовал.

для тестирования браузера мы используем Selenium


А поясните, пожалуйста, про Селениум в контексте нагрузочного тестирования. Как строится тест?
Зависит от проекта, но сам по себе браузерный тест приходится использовать тогда, когда нужно измерить время работы end-to-end (довольно часто хватает отдельного тестирования серверной части и сбора базовых метрик с QA).

Если интересно, могу рассказать об этом на https://heisenbug-moscow.ru/ 8-9 декабря

Selenium в нагрузке используется в двух вариациях:
1) Основную нагрузку подаём JMeter'ом, а Selenium запускаем в штучном количестве. При этом backend загружен на должном уровне, из Selenium'а получаем времена работ браузера (с учётом всех JS/CSS), и не требуется держать огромный ботнет этих самых Selenium'ов. Понятие «огромный», конечно, растяжимо, поэтому я под ним понимаю «более 1-2 браузеров».
2) Нагрузку подаём армией из Selenium'ов. Тут требуется больше нагрузочных машин чем в варианте №1, но при этом мы получаем больше данных за ту же длительность тестирования. Больше размер выборки — больше точность, и больше выбросов мы можем поймать.

Как строится тест?

В чём вопрос? Тест либо пишется специально (наиболее востребованный и/или подозрительный в плане производительности), либо адаптируется имеющийся функциональный. Как правило, в функциональных тестах много разнообразных проверок, которые в нагрузке не столь важны, поэтому 1-в-1 брать не получается.
Sign up to leave a comment.