Почему concurrent connections и RPS нельзя смешивать
В нагрузочном тестировании эти две метрики часто упоминают как будто они взаимозаменяемы, но на практике это разные оси наблюдения. Concurrent connections описывает, сколько одновременных клиентских сессий или активных соединений система держит в конкретный момент. RPS показывает, сколько запросов в секунду реально проходит через сервис. Один показатель больше связан с давлением на соединения и очереди, второй — с фактической пропускной способностью.
Высокий concurrent при медленном ответе может давать относительно скромный RPS, потому что клиенты долго висят и ждут. Обратная ситуация тоже возможна: сервис отдаёт очень быстрые ответы и при небольшом числе соединений успевает прокачать высокий RPS. Поэтому вопрос «что важнее?» в чистом виде обычно поставлен неправильно. Гораздо полезнее спросить: какая из двух метрик лучше отражает наш риск прямо сейчас?
Англоязычное объяснение той же темы находится в Concurrent connections vs RPS. Но для практики на русском важно не только знать определения, а ещё уметь читать графики так, чтобы не сделать ложный вывод о запасе прочности.
Когда важнее считать одновременные соединения
Если вы проверяете API gateway, балансировщик, conntrack, keep-alive pool, WebSocket-слой или любой компонент, который страдает от количества открытых сессий, именно concurrent connections становится главным сигналом. В таких случаях проблема появляется не потому, что сервис не успевает обработать суммарный поток запросов, а потому, что он не выдерживает количество живых клиентов, висящих одновременно.
Для приложений с тяжёлыми ответами это особенно характерно. Долгий поиск, большой экспорт, генерация отчёта или медленный upstream-сервис увеличивают время жизни каждого соединения. В результате RPS может выглядеть умеренно, а система уже захлёбывается по пулам, очередям или памяти. Именно поэтому инфраструктура иногда «умирает на небольшом RPS»: настоящая нагрузка скрыта в длительности и количестве открытых сессий.
Если гипотеза про соединения, не пытайтесь оценивать всё по одной цифре на дашборде. Гораздо полезнее сверить concurrency с latency, количеством занятых воркеров и временем ответа. В связке с нагрузочным тестированием API перед релизом эта метрика часто даёт самый ранний сигнал о будущем инциденте.
Когда важнее смотреть на RPS
RPS выходит на первый план тогда, когда вас интересует throughput приложения: сколько операций в секунду реально переваривает код, база, кэш или очередь сообщений. Это типично для лёгких REST endpoint, статических страниц за CDN, каталогов, поисковых подсказок и любого сценария, где ответы короткие и важен именно поток обработанных запросов.
Высокий RPS показывает, насколько эффективно система конвертирует клиентскую активность в завершённые операции. Но сам по себе он ещё не гарантирует здоровье. Если RPS растёт вместе с p95 latency, ошибками или retry storm, то формально throughput высокий, а пользовательский опыт уже плохой. Поэтому честная интерпретация требует смотреть не только на скорость, но и на качество ответа при этой скорости.
С практической точки зрения RPS полезен при сравнении разных версий приложения, разных правил кэша и разных конфигураций autoscaling. Он хорошо отвечает на вопрос: «стала ли система обрабатывать больше полезной работы?» Однако без контекста конкуренции за соединения этот показатель тоже может обмануть. Полезно держать рядом график concurrency, чтобы видеть, не куплен ли рост RPS ценой перегрева другой части стека.
Типичные ошибки интерпретации
Самая частая ошибка состоит в том, что команда видит «хороший» RPS и решает, что сервис масштабируется отлично, хотя в этот момент нарастают таймауты и длинные хвосты latency. Вторая типичная ошибка обратная: все пугаются роста concurrent connections, хотя сервис стабилен, а увеличение вызвано лишь более длинным, но контролируемым временем ответа на тяжёлый endpoint. Метрика всегда должна читаться вместе с гипотезой теста.
Ещё одна проблема возникает при сравнении разных тестов без одинакового профиля нагрузки. Нельзя честно сопоставлять RPS двух прогонов, если в одном были короткие GET-запросы, а в другом тяжёлые POST с записью в базу. Точно так же concurrency в одном тесте может состоять из краткоживущих клиентов, а в другом из долгих сессий. Без одинаковой формы трафика цифры выглядят похожими, но говорят о разных вещах.
Поэтому в отчёте всегда фиксируйте сценарий, длительность, форму ramp-up и критерии остановки. Это делает выводы переносимыми и помогает не спорить спустя неделю о том, какая именно метрика «важнее» для уже завершённого прогона.
Как эти метрики помогают выбрать план и сценарий
При выборе плана имеет смысл отталкиваться не от рекламной мощности, а от того, какой сигнал вы хотите получить. Если нужно проверить устойчивость к большому числу одновременных клиентов, приоритетом будут лимиты по concurrency и удобство управления длительностью прогона. Если задача состоит в сравнении throughput разных конфигураций, важнее предсказуемо добираться до нужного RPS и фиксировать результат без рывков.
Именно поэтому страница /pricing полезна как инженерный документ, а не как витрина. Вы смотрите на max time, concurrents, наличие API и удобство повторяемых запусков, а затем связываете это со своей гипотезой. Если тесты идут регулярно, имеет смысл завести отдельный рабочий контур через /register, чтобы не смешивать экспериментальные и боевые прогоны.
При этом неизменным остаётся базовое правило: запускать только авторизованные проверки на подтверждённых целях и в рамках /legal. Метрики нужны для инженерных решений, а не для абстрактной гонки за числами. Когда команда держит этот фокус, concurrent connections и RPS перестают конкурировать между собой и начинают дополнять картину.