И первый вопрос от любого чела не связанного именно с нт  и девопсом (и разрабы тож редко знают что то про рпсы). А что значат эти цифры, и как на основе этого вы делаете вывод что тут все хорошо/плохо.

а в чем сложность сделать вывод?

ты ищешь максимум вот максимальный рпс - вывод система больше не держит рпс

или что за пробелма?

для нас ни в чем, но вопросов у костюмера будет проста уйма

начинайте просвящать людей

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

а в чем проблема в этом случае оттолкнуться не от значений рпс а от значений пользвателей с таким же профилем нагрузки? 🥲

заново начинаем?

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

отсюда делаем какой вывод? если вы сказали бизнесу что система держит максимум 1000 пользователей. на следующий день пришло в систему 10000, которые просто нифига не делают, либо очень медленно и слабо тыкают в систему. бизнес прихожит к тебе  и говорит, ты же говорил что там 1000 пользователей максимум? как же тогда туда зашло 10000 и у нас всё работает?
либо наоброт пришли 500 наркоманов и затыкали систему до смерти, снова вопросы.

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

я говорю ровно про это. про уровень интерпретации)

Отличается способом обработки ошибок.
Пусть в тесте 3 ступени.
На первой 0 ошибок
На второй 30%
На третьей 80%

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

А в RPS подходе что будет. Настроено, что надо сделать 300 RPS, но вот проблема, только 2 запроса в сценарии работают корректно.
И система отправит 300 RPS но из двух запросов.
А это совсем другой профиль

Поэтому мне нравится RPS подход, сделанный в Gatling - троттлинг.
Это не RPS это ограничение RPS сверху на профиль, который задан как-то еще.
То есть, можно задать профиль в потоках.
Но сверху ограничить RPS, тем самым выровнять RPS
Вот это идеал профиля нагрузки для меня.

Аналог тротлинга Gatling в JMeter - два Constant Throughtput Timer, один во Flow Control Action, а второй на всю группу (для запросов)

А чистый RPS подход - увы нет

Честно, я и не заканчивал 🤣

Не приемлю я одного "универсального" подхода, хоть убей

ну это же не говорит о том что нам надо по кругу ходить и мне отвечать на одно и то же каждый раз)?

Привет всем! Есть ли какие-то способы посмотреть статистику основных метрик утилизации ресурсов подов в опеншифте за сутки

можно обработать ошибки через try catch а вообще наверное стопать надо если у тебя 30%)

При неработающем прометее

неа, вроде нет

сюда добавлю что SLA чаще на ошибки сейчас в районе процента. т.е. даже если у тебя начнутся ошибки то твоя точность упадет на этот процент максимум

Пока не понял все тезисы твоей переписки с Володей, не все прочел

Мой тезис - закрытая модель нагрузки нужна

А по дискуссии
Открытая тоже нужна, но если ее делать.
То сделать лучше, чем в Gatling. Сделать отрытую модель нагрузки, в которой будет верхний лимит на количество потоков. И если таймер решит создать 10 000 потоков, а лимит 1000, то он просто подаст 1/10 планируемой нагрузки и это ок