Как я сократил код для нагрузочного тестирования в три раза

[AnthonyKot]

У К6 еще есть классная фича — портирование Postman коллекции в тест. И спасибо за статью =)

[HackFeed]

Это, да, не затронул данную тему в статье, потому как это больше все-таки про HTTP, а мне больше хотелось сделать акцент на тестировании по бинарному протоколу :)

[nskforward]

На чистом Go легко пишутся сложные нестандартные нагрузочные сценарии с выводом любых метрик в Графану, если вы умеете готовить Go для нагрузочного тестирования. Не очень понятно, зачем писать модули/коннекторы и сам сценарий на разных языках, когда можно всё сделать гораздо проще и быстрее. У нас очень сложные нестандартные асинхронные сценарии с проверкой состояния параллельных потоков данных, нам пришлось писать скрипты на Go. Со временем, мы перевели все остальные проекты на него, так как мы влюбились в простоту, скорость разработки, поддержку и отсутствие каких-либо даже теоретических технических ограничений. Универсальные части легко выносятся в модуль и вы пишите только бизнес логику. Также удивило насколько эффективно используются ресурсы машины генератора при работе на ней Go скрипта. Если на одной машине сравнивать одинаковый сценарий с тем же JMeter, то разница на порядок не в пользу JMeter по максимальному исходящему RPS и максимальной утилизации ресурсов генератора. Если вас полностью устраивает ваш инструмент, то, наверное, ничего менять не нужно. А мы свой выбор уже сделали.

[oneumyvakin]

Поддерживаю. Ещё плюсы в том что:
— можно легко передать коллеге и коллега в Go коде всегда разберется
— экосистема Go достаточно стабильная, код написаный 3 года назад скорее всего заработает на новой версии, зависимости никуда не исчезнут и не сломают API

[HackFeed]

Понятие "проще и быстрее" достаточно растяжимое. Мы просто подстроили существующий инструмент под себя, внеся не самые значительные изменения. По сути на нашей стороне мы просто написали модуль взаимодействия с БД, все остальное (сбор, агрегация метрик и т.п.) взял на себя инструмент.

[nskforward]

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