имхо руками почти всегда быстрее при таком изменении системы

если речь о всякой статике без бодидат, то можно ксарники сравнивать как помощь...

19 000 на двух потоках, при тесте локального сайта

Впечатляет)

Это попробовал перейти с HTTP Client4 на Java Client

офтоп, а почему именно 2 потока?

Ещё есть другие варианты добиться того же. Суть одна - соединения переиспользуются. По одному на поток. И поэтому запросы отправляются максимально быстро.

У меня 4 ядра на ноутбуке. Два отдал на JMeter, одно на nginx, одно себе оставил

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

Гуся то пойдет кто слушать завтра? 🙂

Я не пойду, но наши ребята будут

Я вот в раздумиях ехать или нет, там запись будет интересно?

есть вариант, к апишке делать сваггер, который актуализирует разработка, в нем все методы актуальные. делаем после релиза обход методов, методы которые отличаются от прошлого состояния выводим в виде курл запроса - далее используем курл импорт в жметер, и все семпл готов. после этого копипастим логику если не менялась и пост/препроцессоры. курл генерить умеет сам сваггер, обход можно делать питоном, запросы можно не совершать даже, просто парсить тела и сравнивать. для себя сделать excel детализацию сценариев, чтобы понимать в каком сценарии/скрипте используется данный запрос (для больших проектов)

сваггеры подобные - хороший тон в разработке
альтернатива - конфлюенс с телами запросов, его тоже можно попарсить

Хм, как я понял он как раз не про апи говорил, @Ganeles  можешь чуть шире раскрыть "не на API а на всё остальное"?

Это можно делать прям из жметра:
1.смоук тест
2.если есть падения берем переменную пути запроса
3. по ней делаем сбор новой информации и выводим в лог - все в одном окне

а, мой косяк - не внимательно прочитал

тогда тоже не очень понял)

Сваггер есть
Но методов в нём штук 50 а используется в моих скриптах меньше половины

Вообще я думал об этом
Пока в плане api остановился на том, что после каждого релиза выгружаю оттуда swagger.json, и сравниваю со старым