спасибо за мысли

Спасиб! java не зашла, забыл что на серваке нет интернета) сделал через COPY👍

Если делать на Gradle, то запуск JMeter будет одной командой.

Вон сейчас вообще целиковый JMeter можно запустить из исходников одной командой: gradlew runGui и собираются вообще все нужные JMeter’у jar’ники и запускается GUI.

Так же и вы для себя можете сделать. Проект, в котором будут нужные вам классы, и будете запускать jmeter (gui или console) аналогичной командой.

Плюс будет в том, что все эти скрипты будут хорошо показываться в IDEA, с автодополнением и т.п.

—

Так-то, думаю, можно либо уже как-то, либо сделать фичу, чтобы JMeter брал скрипты в момент начала теста, но разрабатывать код без автодополнения, без тестов я бы сам не стал. Ну, реально, узнать, что «вызываешь несуществующий метод» только через полчаса как началась нагрузка это такое себе удовольствие.

Спасибо, если это реально отображается в IDEA , то это уже намного лучше

Надо разобраться

Володь, ты не в курсе сохранение в md5 повлияет на время receiving?
Elapsed - latency. У меня на толстых запросах времена эти в космос улетают. Но не могу понять как повлиять на время вычитывания из сокета

@smirnovqa может ты в курсе?

И похоже в данной истории таки важны треды))

судя по имплементации на это никак не повляить

Замедляет ответы небольшого размера. Да.

Но естественно ускоряет JMeter, если ответ был на 100 Мбайт. Хеш от него в памяти хранить просто

Галочка нужна лишь для больших ответов. Огромных. Для которых ты тело хранить не хочешь

Вроде, не должно.

Но, к слову, в новых версиях Java ускорили работу MD5 / SHA1 за счёт CPU инструкций — это ещё один повод обновлять Java

https://bugs.openjdk.java.net/browse/JDK-8250902: Implement MD5 Intrinsics on x86

Выкатили в 16+

сохранение респонса же не входит в респонс тайм суммарный

тогда и мд5 на него влиять не будет

ну это круто если бы у меня была ресурсная проблема

понял, спасибо

но в целом не понял как повлиять на респонс тайм если проблема в долгом ресиве на стороне jmeter. потенциальное решение - увеличить треды, чтобы было больше сокетов?

кажется не особо решает)

Т.е. проблема сводится к пониманию того, «что же делает jmeter»: что-то делает, или реально пытается вычитать из socker’а.

Проверял «вычитывание» чем-нибудь другим? Т.е. проблема только в JMeter воспроизводится?

JMeter ждёт ответа? Т.е. cpu% на стороне JMeter стабильно 0? В треддампах JMeter висит на socket.read или на чём-то другом? JFR / async-profiler не пробовал натравливать на JMeter?

Какой воообще объём передатваемых данных? Ширины сетевого канала хватает, чтобы прокачать трафик?

хорошие вопросы!
Объемы не большие - поэтому вся эта история вызывает подозрения. 3 мегабайта тело ответа и у меня разница между elapsed и latency 316 сек. Проверок не делал - хотел сначала понять как можно исключить jmeter из влияющих факторов.
Аплинки 10 гбит, данные даже на 30% его не утилизируют. Тредов было всего 1000. Не знаю есть ли пропускная способность у сокета и может ли она деградировать - но кажется что он должен быть сильно производительнее.
Хочется задетектить это приложение медленно пишет в сокет или я медленно читаю. По метрикам самой сети я явных проблем не вижу.
Профилировать конечно можно, но особого профита не вижу, увижу что jmeter висит на socket.read, а это же показывают результаты в виде elapsed-latency. Проблема снятия треддампа в том что не все запросы такие печальные а только выборочные и словить момент когда такое произойдет сложно - поэтому тут только в онлайне жаву мониторить