Опять же какой тип теста вы хотите сделать, что хотите получить в результате
Конечно от системы зависит, рампап из расчета 1 секунда на юзера более менее реалистично

цель: получить среднее время ожидания ответа в зависимости от количества пользователей (которые шлют запросы одновременно). выполнять тест больше 600 секунд на группу не могу - у меня авторизация по токену и он живёт 600 секунд. Т.е мне за 600 секунд (было 700 в группе, я знаю. да)) нужно получить результат

Иначе говоря нужно понять сколько времени в среднем проходдит от момента отправки запроса до момента получения ответа при условии, что запрос шлёт одновременно n-человек (n пределах 100 - 1000 с шагом в 100)

Мое мнение конечно не очень авторитетное но среднее время  это что-то вроде как в том анекдоте - кто то ест капусту, а кто то мясо, в среднем у нас голубцы.
Медиана и персентили дают более как то реалистичные и наглядные данные

А сделать реквест на запрос и сохранение токета раз в какое то время ну и с проверкой жив ли еще естественно

ок. Я в сообщении выше написал, что хочу получить - можете посоветовать как настроить jmeter (1 группу в 700 пользователей) и какой тип отчёта выбрать? Спасибо

Я не знаю какой у вас доступен но впринципе Aggregate report уже встроен и плагин для графиков можнл стянуть для наглядности

так и делаю. Но без проверки жив ли. В общем схема у меня такая (мб не верная, я "нагрузочный тестировщик" 4 день)) 1 группа на получение токена (выполняется 1 раз и передаёт свойство) за ней группа с 100 пользователей ramp-up period 100 секунд потом опять получение токена и группа на 200 пользователей и т.д.

ок А какой ramp-up period выставить?)

Если у вас ограничение в 600 секунд то с 700 будет все же проблема но если нет и нет возможности сильно затягивать тест:
Юзеры 700
Рамп ап 700
Луф галочка на форевр
И дюрейшн поставьте допустим (750 - хоть 50 секунд все юзеры вместе побегают, но я б на вашем месте попыталась 1400 сделать что бы наглядность результатов была )

ок. А если рамп ап снизить (до 100 пользователей в 10 секнуд, например)) - будет сильная нагрузка на сервак?

Ребзя, привет,

Возник такой вопрос. В аплике периодически тригерится пара важных запросов (раз в минуту, и раз в 4 минуты). Тригирятся они просто в паралели со всеми, т.е. прявязаны только ко времени. Есть ли какой то способ завязать все это дело без паралель контроллера?

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

Ну параметризация наше все но даладно)
Можно в установке токена записать время его создания (гдето вынести переменную с вприницпе длительностью жизни токена, переменная с временем когда создали последний и его перезаписывать)
Потом в начале каждого треда(допустим, смотрите по логике) и семпл з чекином времени карент тайм-создание токена тайм = .... > время жизни токена и тогда вызывать создание токена нового

Не реалистично(хотя кто знает вашу систему)
Таки да это ваше железо пожалейте его
Результаты будут склонятся к стресс тестированию чем к просто лоад

Даже если запрос выполняется 30-50 сек, вам хватит одного потока для данного профиля нагрузки "1 в минуту". Пусть с запасом - 2. Это несущественно мало.

я тоже так решил, что это стресс будет больше. Начальник дал добро положить сервак :->) так, что  в принципе можно пробовать).
По поводу перезапроса токена такой затык: токен нужно получить одним пользователем, поэтому я его получаю в отдельной группе. Также у меня 10 групп, которые запускаются последовательно  (сначала тестим на 100 пользователях, потом на 200 и т.д. и перед каждой группой получаем токен). Если же я встрою получение токена в группу с 100 пользователями - я получу 100 токенов) поэтому получение токена не возможно (при текущем конфиге) пока выполняются запросы... Но это мелочи. Я в принципе понял что не так - буду пробовать. Спасибо

Вы можете сделать простой сценарий:

В Test Plan получение значения переменной THREAD, из ${__P("THREAD")}

Потом получение токена, сохранение его в property TOKEN. В SetUp Thread Group.

Потом Thread Group, где стартует ${THREAD} потоков. В них сценарий использующий ${__P("TOKEN")}.

И запускайте тесты из консоли, передавая в качестве аргумента THREAD. Вы получите на выходе 10 отчётов. Или один отчёт, если используете influxdb и Grafana.

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

Тоесть он точно так же как у Константина будет 1 раз перед тред группой запускатся и его реньювить не получится все же как я поняла

А зачем вообще рамп, если сразу всех надо?