у меня заказчики наоборот зачастую требуют именно в пользователях ответ

Если «нужное количество RPS может выжать один поток в одой http сессии», то результаты тестирования считаем успешными?

А, если окажется, что реальные пользователи никогда не делают logout, в результате они плодят кучу http сессий, которые занимают море памяти на сервере?

Поэтому «60 запросов в минуту» для случая «все 60 запросов делает один пользователь в рамках одной сессии» и «это 60 разных пользователей, которые работают каждый со своей сессией» это вообще разные профили нагрузки, хотя и там и там как бы 60rpm 🙂

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

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

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

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

зачем тут про юзеров тогда?

ахаа))

В основном мы пишем отчеты не для технарей, а для манагеров из бизнеса. Уже 100 раз было, что ты пытаешься выразить пределы нагрузки в рпс\тпс, а они приходят и говорят что нифига не понятно. Напиши в пользователях

и это кейс крайне частый

так ты споришь за то чтобы нагрузочники писали лишнюю инфу в отчетах чтобы это нравилось манагерам?

Тема с рпс на моей памяти работала, на паре проектов, где заказчик и менеджмент хотя бы шарили за то что такое рпс

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

Возможно, в продуктовых фирмах это не надо, но по моему опыту в аутсорсе это очень важная инфа (для заказчика)

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

Умение выдавать executive summary это крайне полезный навык.

Да, возможно, существуют случаи, когда от результатов нагрузочных тестов ждут море цифр и графиков, но, полагаю, мало кто откажется от иерархического варианта: «как у нас в целом?» «с чем проблемы?» «что нужно делать?» и уже потом детали.

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

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

никак пользователи тут не помогают же

-- как наши дела?
-- херово.
-- а почему херово? а вы точно правильно тестируете? а давайте мы всё проверим и дадим вам много советов?

++
мы вот уже давно делаем максимум мини-отчеты:
Дата
Сценарий в 1-2 предложения
Выводы
Рекомендации (что дальше)
Пара графиков подтверждающие выводы