Спасибо!

всем привет,
задача: нагрузить grpc сервис, использую jmeter(хочу именно им, уже есть наработки + хочу JmeterDsl докрутить что бы из кода jmx создавать, в общем, не переубеждайте), нагуглил два решения:
1. sampler но с ним что не могу понять, в каком формате и куда задавать сообщение
2. plugin которым нужно нагенерить семплеров с расширением jar и положить в jmeter/lib/ext/ если правильно понял нужно создать на каждый метод сервиса jar файл вида my-grpc-sampler.jar(если у сервиса Х методов то будет Х jar)
не один из вариантов пока не удалось запустить, может есть у кого пример реализации или другой вариант решения поделитесь плиз, наставьте на путь истинный (но в рамках jmeter ;) )

а при чем тут JmeterDsl и какой DSL? я так понимаю сейчас реализация на нём требуется? и что за плагин не ясно и какой семплер юзаешь тоже

JmeterDsl это к слову пришлось(позже могу рассказать детальнее), сейчас хочу реализовать Jmeter скрипт.
1. sampler https://github.com/zalopay-oss/jmeter-grpc-request
2. plugin https://github.com/zalopay-oss/jmeter-grpc-plugin

по grpc не подскажу, по крайней мере пока не увижу как ты пытаешься это сделать. а про дсл хотелось бы послушать

Тредгруппу тестируй уже. Потом dsl на Котлине запилим

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

плюс как раз DSL изучал, кривовато написано, заведу туда ишью ещё парочку и кое что сам поправлю. надеюсь оно пригодится как исходник)

Вот эта либа Java JemeterDsl https://github.com/abstracta/jmeter-java-dsl

Есть ещё такой вариант: https://github.com/anasoid/jmeter-as-code

понял, я про нее уже всем уши прожужжал за последние 3 недели

Сори, не успеваю все читать)

У меня план примерно такой: сделать непрерывный пайплан от функционального тестирования к нон-функциональному,

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

Функциональное тестирование: из опенспеки генерить тесты, а именно интерфейсы, из интерфейсов строить пирамиду тестирования, к нужному интерфейсу подключать дата сорс(бд или файл не важно), пирамида по слоям, на каждом слое тестов меньше:
1. параметры запросов и коды ответов (10к)
2. интеграция с данными (1к)
3. специфик кейсы (регрессивные баги или хай приоритет)(500)
4. клиентские паттерны запросов в различных дата фреймах и др дименшенах уже в разрезе Юайя клиентов(100) у меня клиентов 5 и каждый юзает свои паттерны, те один запрос и одинаковые параметры, но запросы за день/неделю/месяц/год
5. переход к нон-функциональным запускам с использованием джеметр, те же тесты что в п4 но уже интегрируем в перф модель с помощью дсл
*хочется что бы после генерации функциональных тестов перф модель сама подхватывала новые иньерфейсы и загружала их в модель/фрагменты

интересно конечно, но должны быть довольно странные цели у этого всего для того чтобы в нагрузке адекватно можно было использовать функциональные тесты

посмотри в сторону экспорта из сваггера в jmx, ещё постман можно туда грузить, может поможет

цель очень проста,  снижение цены бага,  каждый из слоев работает на своём енве(dev-qa-stage-perf)

А что за экспорт?
Я перехватывал запросы из сваггера фиддлером и конвертил в jmx, или руками семплеры заполнял
А есть автоматический способ?

пока не пройден уровень выше не переходим к следующему