Хотя наверное я не так всё понял)

В закрытых сетях, где пакеты тянутся из atifactory / nexus / ..., а не из открытого интернета с maven central, гораздо стабильнее работает и более прост в настройке maven. На три порядка проще. SBT тоже нестраивается, только при невозможности найти пакет в локальном репозитории переходит в режим "торможу"/"вишу"/"жду чуда". Столько проблем словили с этим, даже не самим SBT, а с его интеграцией с IDEA, что пришли к единственному надежному варианту настройки - качать пакеты через maven, если sbt их найти не может. Или вообще качать кеш пакетов на новую станцию со станции, где пакеты уже скачаны.

Если интернет доступен, то sbt нативнее.

Не на ходу, при запуске, но без изменения кода

Не знаю какие там проблемы, добавил строчку resolver и все ок

Ребята привет, нужна помощь по направлению куда думать,
составил скрипт ориентированный на поведение пользователя: условно определил задержки констант таймером (3 сек между апи запросами, на мой взгляд это +- самый быстрый сценарий проходжения) период рампап взял 40 сек также ориентированно на игру и запустил 80 потоков - время ответов я получил больше чем требуемое  (скрин), мне нужно уложиться в 3 сек. Я уменьшил кол-во потоков до 50 и ответы получил на границе допустимых пределов. Т.е. вывод из теста -это максимум 50 юзеров.
Я недавно тут спрашивал на тему как определить максимальное число пользователей чтобы при их действиях ответы не превышали 3 сек, мне подсказали ориентироваться не на юзеров а на РПС, но допустим если в моем сценарии снова поставить 80 потоков и таймер Throughput или контроллер Throughput и ими оперировать то посути мы за счет изменений интенсивности добиваемся нужного результата что не совсем верно на мой взгляд. Где я не прав? уточню что кол-во потоков после подьема в процессе теста не должно меняться.

привет, смысл ориентации на рпс в том, что он честнее отражает ситуацию. те пользователи которых ты нашел - не существуют, пользователи с задержкой в 3 сек между запросами, это в реальности какой процент пользователей? а насколько точно именно 3 секунды? все эти вопросы могут сказать о том, что три секунды это грубая оценка. а это может сказать о том, что задержка может быть и 3.5 сек, учитывая погрешность оценки, а тогда юзеров будет существенно больше. суть в том, что распредение времени задержек между запросами у каждого свое - бабушка тыкает раз в 2 минуты, а суперхакер раз в секунду. средний портрет пользователя сложно получить верно. его можно предположить, например сказав что задержка между его запросами 3 секунды. но смотреть рекомендую исходя из запросов в секунду, а уже эти результаты переносить на пользователя. в этом подходе вы можете имитировать работу ста реальных пользователей одним виртуальным. а результаты просто правильно интерпретировать. более того фиксированные задержки не очень верно реагируют на увлечение времени отклика, в случае если отклик растет пользователь меняет свое поведение и совершает меньше запросов, так как дольше ждет ответ. но все ситуативно и зависит от системы. если в нее реально идет 1 запрос в 3 секунды константой от одного пользователя, если я правильно понял как вы грузите - тогда это верно)

в пользу подхода рпс могу еще дать такой пример:
если со временем юзеры будут быстрее делать запросы к системе (например), то вам нужно просто иначе интерпретировать результат, а не менять весь скрипт)

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

если знаем точные рпс - всегда можем интерпретировать их как угодно

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

правильно - снимать статистику и задавать распредение

ты получаешь 1000 рпс в сутки, смотришь сколько за это время было пользователей. смотришь какая операция была чаще какая реже - получаешь процентное распределение. это твои 100%, далее для поиска максимума ты берешь шаг например в 10% и увеличиваешь на него каждый раз - таким образом находишь реальное число, в момент когда система перестает удовлетворять требованиям - это по сути и есть максимум. далее обратно интерпретируешь в пользователей

лучше брать статистику за пиковый час

я недавно выступал с этой темой, сейчас дам материалы

Ну в тему материала есть еще The Art of Application Performance Testing by Ian Molyneaux

вполне себе чтиво на пару вечеров

образно понятно но начинаю думать конкретно и не понятно с какого вопроса начать)) Спасибо обоим за материалы надеюсь после прочтения станет более понятно

если нужен поиск максимальной производительности - то это поиск максимума, без вопросов)