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

Что хотят услышать интервьюеры:

Нужно показать, что показатель запросов в секунду зависит от типа системы, железа, архитектуры и профиля нагрузки. В ответе важно не называть «магическое» число, а уметь объяснить порядок величин и факторы, которые его ограничивают. Хороший ответ обычно звучит как ориентир: сколько система выдерживала, при каких условиях и где был потолок.

Определение:

Запросы в секунду, или RPS, — это количество входящих запросов, которое система обрабатывает за одну секунду. Для высоконагруженных систем это один из базовых показателей производительности. Он помогает оценить пропускную способность сервиса и понять, где находятся узкие места.

Пример использования:

Например, API-сервис для каталога товаров в тестовой среде на одном экземпляре приложения может держать несколько сотен RPS, а при масштабировании и оптимизации — несколько тысяч RPS на инстанс или больше на весь кластер.

# Условный пример оценки RPS по результатам нагрузочного теста
total_requests = 120000
test_duration_seconds = 60

rps = total_requests / test_duration_seconds
print(f"RPS: {rps}")

В этом примере за минуту обработано 120000 запросов. Делим на 60 секунд и получаем 2000 RPS.

Пояснение кода:

Код показывает простую оценку средней пропускной способности.
Сначала берется общее число запросов за тест.
Потом это значение делится на длительность теста в секундах.
Результат — средний RPS за весь период измерения.
На практике дополнительно смотрят p95/p99 latency, ошибки и распределение нагрузки по времени.

Ключевые моменты:

• RPS не имеет универсального «нормального» значения: оно зависит от домена и условий теста.
• Важно уточнять, это RPS на один инстанс, на кластер или на всю систему.
• На показатель сильно влияют база данных, кэш, сеть, CPU, I/O и задержки внешних сервисов.
• Для собеседования лучше говорить не только число, но и контекст: размер нагрузки, время ответа, процент ошибок.
• Часто важнее не максимальный пик RPS, а устойчивый RPS при приемлемой latency и без роста ошибок.