Комментарии 4
Позвольте не согласиться с главным постулатом статьи: это не статья про тестирование. Это статья - реклама конкретного облачного инструмента. Если инфраструктура готова пустить нагрузку снаружи без vpn это просто безумие, равно как и тестирование продуктового контура, что, впрочем, практикуется с госуслугами, как мы знаем. Тестирование из облаков огромная проблема, с которой не справляются даже агенты в приватном контуре. Результаты тестирования тоже могут попадать под nda и это совсем не редкость. Банки и правительственные органы никогда не готовы к облачным сервисам. Узкий круг использующих нагрузочное тестирование в компаниях РФ скорее ориентирован на JMeter.
Добрый день, спасибо что прочитали статью! Вы меня не так поняли)
У нас обратная ситуация происходила. Когда мы только начинали стартовать в НТ, то пробовали несколько инструментов, и Jmeter в том числе, но после исследования остановились на k6. И мы остановились на бесплатном решении со всем многообразием open source библиотек k6. Запуск реализован внутри нашей инфраструктуры через pipeline CI/CD и на контурах, которые тоже спрятаны внутри.
Я знакомилась с облачным enterprise решением k6. Это конечно космос. Но соглашусь с вами - подавать нагрузку откуда-то из вне, хранить результаты и копию кода на внешних по отношению к компании серверах - крайне сомнительная идея.
Спасибо за ваш комментарий, это навело меня на мысль в след части более подробно пояснить как работает код и как он встроен в нашу инфраструктуру.
Тут всё очень зависит от продукта и круга пользователей. Для международных бизнесов и сервисов можно без облаков, но тогда нужно ставить своё оборужование распределенно в мире. Требования регуляторов и для улучщения доступа. Если компания международная, но еще не уровня FAANG и не готова строить собственные датацентры, то облачные решения вполне себе выход. А соответственно и нагрузку лучше подавать из облаков.
Я сейчас занимался анализом и подбором инструмента подходящего для нагрузочного тестирования.
jMeter - не впечатлил наборами тестов в XML формате. Хотя, возможно, я что-то не до конца понял. K6 выбрали, так как нам нужны специфические плагины, а продукт написан на GoLang. Так что разработчики смогут помочь с плагинами.
Хотя если бы не это условие, я бы остановился на Gatling. Совместная инфраструктура кода тестов и самого фреймворка - гораздо лучше в перспективе. Ну и полный доступ к библиотекам Java/Scala тоже огромный плюс.
В K6 - нужно писать тесты на JS, но при этом нет поддержки Node.js, т.е. лишаешся огромного колличества библиотек. Банально для работы с файлами уже нужны сторонние библиотеки.
Также не впечатляет ограничение на запуск единственного файла с тестами. Пока еще только думаю как с этим жить. Т.е. нормально разложить тетсы по файлам, чтобы не иметь простыни на кучу строк - не очень-то получается. Вроде как можно импортить файлы, но тогда не понятно как быть с тагами и как выбирать что импортировать.
Пока что самый очевидный способ управлять группами тестов - это банально указывать разные файлы на уровне пайплайна, что не самое удобное решение.
Я никоим образом не защищаю и не рекламирую JMeter. Это убогость. Он неудобен и безумно прожорлив. Я упоминал его только, чтобы констатировать приверженность рунета к нему. Говорю о том, что знаю. И я никогда не мог понять восторга от гатлинга. Его приводили в пример, когда заходил разговор об Iot близких протоколах или тестировании брокеров сообщений. Меня не впечатлил тогда. Скорее всего, когда ты разрабатываешь конкурента тебя ничего не впечатляет :) У меня был неприятный момент с нодой в качестве тестового движка. Люди привели его в пример тому, за что я отвечал. Количество генерируемых нодой запросов было на голову выше. Оказалось, что нода оптимизирует их и посылает одним пакетов, буферизируя. Это очень правильно с точки зрения клиента, но не с точки зрения тестового движка. Я не говорю, что любой тест на ноде будет от этого плох. Но нужно очень хорошо знать реализацию использования клиента, чтобы ручаться за результаты, если это нужно. Часто бывает так, что нагрузочное тестирование просто не нужно или слишком дорого.
Нагружаем и отдыхаем: load testing без стресса, ч.1 — процесс