Чтобы точно контроллировать значение запросов в сек, используйте Тротлинг.

а вот такой вариант setUp(Notifiaction.inject(constantConcurrentUsers(100) during(1 seconds)).protocols(httpProtocol)).maxDuration(20 seconds) он отработал ровно 20 секунд..... т.е. 100 юзеров в делали вместе 100 запросв/сек на протяжении 20 сек

Не исследовал пока. Надо поразбираться - планирую. Здорово, что пишите о результатах

#антипаттерны

Не буду говорить, что где-то есть ошибка. Просто заметка.

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

Вот лично вы уже поняли, что такое шаг нагрузки - длительность работы одного пользователя. Так вот, реальный пользователь работает с системой не 1 сек, а 5-30 минут. За это время кто-то делает 1 запрос, кто-то 200. Интенсивность (RPS) от того, который делает 200 запросов за 5 минут = 200/5/60 ~= 0.67 в сек. Это максимум, а от того, который делает 5 запросов за 10 минут ~= 0.0083 запроса в сек.

Пусть мы работаем по профилю - 1000 пользователей, которые делают 5 запросов за 10 минут (каких-то конкретных запросов, конкретной группой параметров). То они создадут интенсивность:
1000 запусков в сек, но в среднем лишь
1000*0.0083 = 8.3 запроса в сек. Не 1000 в сек, а 8.3 в сек.

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

Но если вы поставите себе цель 1000 запросов в сек, или более того, 1000 успешно выполняющихся сценариев в сек (пусть в каждом сценарии Notification будет по 3 запроса), то это 3000 конкретных запросов в сек. То можете ошибиться с требованиями. Завысить их. А потом система выйдет в продуктив и окажется неожиданно быстрой, хотя не должна была держать нагрузку.

Верно считать профиль нагрузки в запросах в сек, в транзакциях в сек, но не в пользователях, имея в виду реальных пользователей.

Основывать расчет профиля (в RPS) лучше на анализе статистики работы пользователей, или хотя бы интеграционных автотестов (с Selenium). Сконвертировать пользователей в RPS.

Но тем не менее, производительность измеряемая в пользователях инструмента нагрузки является критерием.

Например. Пул из 2-х потоков, работающих в Gatling/JMeter/SoapUI/... без пауз в цикле развивает интенсивность работы 70 запросов в сек. Вот если взять это за критерии, то когда производительность системы разработчики увеличат, то 2 потока/пользователя смогут за счёт того, что быстрее получают ответы на запросы, отправить и получить больше результатов, и покажут уже 170 запросов в сек, например. Это будет критерием, что производительность стала выше

И также можно делать тест на 1000 одновременных [подключениях/стартах/нагрузочных пользователях/потоках] (точное определение зависит от инструмента и конкретных настоек) и получать в качестве метрики среднее время отклика или достигнутый показатель RPS. И сравнивать этот показатель от теста к тесту.

Но связи с реальными пользователями тут может не быть.

Это самое сложное при коммуникации с бизнесом. Бизнес понимает только две метрики - количество одновременных пользователей и количество покупок/ставок/etc в единицу времени. Потому если приходится показывать отчёты бизнесу, то надо хотя бы костылями за уши притянуть количество потоков к реальным пользователям, во избежание дурацких вопросов

Плюсую, что это боль, при общении с бизнесом. Ребята ориентируются на количество пользователей, а НТэшники смотрят на rps, tps, ops. Если пользовательский сценарий выполняется медленно, то нужно подкинуть еще одного пользователя в параллель, чтобы покрыть требуемую нагрузку)

Чего сразу боль то - работа. Преобразованием одних метрик в другие и живём

Кстати, бывают случаи, когда мерять в Пользователях необходимо:
Это количество онлайн-пользователей влияет на работу системы, и это надо учитывать во время НТ:
Чаще всего это означает, что:

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

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

Для частности. Никогда не получаю четкие требования по профилю нагрузки.

И поэтому сначала их приходится рассчитать. А потом придти и согласовать.

Внимание в этом профиле обращают на пропорции операций:
0. Открытие без входа - х10
1. Вход - х1
2. Список документов - х2
3. Создание - х0.2
...

На полноту по тестовым данным. И на то, как это конвертируется в пользователей. Например, они входят с частотой 20 в минуту, такой интенсивности по операции 1. Вход надо достичь.

И тут либо получится ее достичь. Либо нет. Ищется максимум, как правило в начале.

Потом тест на стабильность.
Подтверждающий.

Ну да, у меня недавно была драматургия по этому поводу, я здесь об этом тоже писал. Кстати история в итоге упёрлась в то, что вместо 100к пользователей карася урезали до нескольких десятков запросов в секунду, потому что это условие провайдера связи (дальше тариф резко дорожает до конских величин). Естественно этот факт никак нельзя было выяснить и утрясти до того как мне выдать безумные требования по нагрузке.

Так это правда. Как правило просто хотят знать выдержит ли сервер столько то пользователей. Но никто не задумывается что здесь миллион факторов может быть. Поэтому приходится самому придумывать очень очень грубые какие требования (вместе с разаработчиками). И потом понимаешь, что Гатлинг дает очень много всяких широких возможностей, с которыми хз как работать. Невольно думаешь возьму я Джмитер дам простой профиль нагрузки где четко будет 1 поток = виртуальный 1 пользователь (сложного там особо не придумаешь) и все ... Так как детальных данных для нагрузки и так нету....

Чет мне кажется в этом плане разницы между гатлингом и джиметром быть не должно

Почитал тут про пользователей и инструменты тестирования и как они искажают восприятие нагрузочных тестировщиков. И хочу вот накинуть такую тему для обсуждения в связи с этим со всем. По-моему когда говорят предъявляют требования о том, что в системе должно работать одновременно N пользователей, то подразумевается тестирование объёмов всё таки. То есть в этом случае пользователь соответствуют не потокам или процессам, и вообще не тому как это в инструменте реализовано, а соединениям. Ну во всяком случае по-моему эту деталь довольно часто упускают из виду

И все в общем то довольствуются большими рпс-ами которые в 1 соединение летят

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

И всегда есть допущение о том 100 рпс с одного соединения/сессии эквивалентны 100 рпс с 2000 соединений

Но может быть и не так

Поскольку вот есть же проблема 10к для серверов, которые на пулах потоков работают