https://github.com/polarnik/gatling-report-example/blob/master/src/test/scala/io/qaload/gatling/reportExample/simulation/CloseModel_IncrementConcurrentUsers.scala

У тротлинг приоритет выше, чем у количества потоков.

А параметры закрытой модели подбираете исходя из шага нагрузки - pase.

И на количество потоков особо не смотрите. В Gatling HTML report количество конкурентных потоков не отображается нигде. Потому что там открытая модель в приоритете. И потому что те, кто пробует сделать из потоков реальных пользователей, попадают в ловушку мышления, из которой не выбираться. И лишь dead line, может вытащить их

Всем доброго времени суток, подскажите пожалуйста, можно ли в гатлинге, увеличивать количество юзеров до достижения определенного RPS? Я имею ввиду что нужно протестировать, что сервер способен обрабатывать 200rps, а также , что он выдержит допустим 1000 юзеров или сколько нужно для генерации 200rps?

а какая у теяб модель нагрузки

Привет, думали начать с открытой посмотреть на что система способно, ну а потом, исходя из полученных данных делать закрытую модель. Но сегодня кастомер сегодня, дал вводные 1000 юзеров, и 200 рпс и это должен быть гатлинг, а я только джиметр знаю). Как то так.

Всем привет! Через жиметр отправляю запросы типа insert, затем, после вставки в таблицу, мне необходимо выполнить апдейтстроки, что я вставил предыдущим инсертом. Загвоздка в том, что transactions_id генерится sys_guid(), как мне передать значение sys_guid из предыдущего inserta в текущий update?

Всем привет. Есть вопрос по CSV_Data_Config Throughput_Shaping_Timer и bzm Concurrency Thread Group c функцией tstFeedback. Вопрос след - Throughput_Shaping_Timer, bzm Concurrency Thread Group c функцией tstFeedback контролируют уровень нагрузки и используемый пул тредов для обесепечения нагрузки. Проблема в том, что треды переиспользуются, а данные из CSV_Data_Config обновляются только при выполнении нового треда. Кто то с таким сталкивался?

Всем привет. Есть вопрос по CSV_Data_Config Throughput_Shaping_Timer и bzm Concurrency Thread Group c функцией tstFeedback. Вопрос след - Throughput_Shaping_Timer, bzm Concurrency Thread Group c функцией tstFeedback контролируют уровень нагрузки и используемый пул тредов для обесепечения нагрузки. Проблема в том, что треды переиспользуются, а данные из CSV_Data_Config обновляются только при выполнении нового треда. Кто то с таким сталкивался?

Данные должны читаться при новой итерации, а не при новом треде

Данные должны читаться при новой итерации, а не при новом треде

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

работают в хронографе но не работают в графане, а отказался от хронографа?