RPS и QPS

Базовый System Design
≈ 2 мин чтения

RPS показывает интенсивность входящих запросов

RPS — requests per second, количество запросов в секунду. Это одна из самых удобных величин для быстрой оценки нагрузки, потому что она переводит большие суточные числа в темп, с которым система реально получает работу.

Если сервис обрабатывает 8,64 миллиона запросов в сутки и запросы распределены равномерно, средняя интенсивность будет около 100 RPS.

8,640,000 requests/day ÷ 86,400 s/day = 100 RPS

Это именно среднее. Оно полезно как отправная точка, но не говорит, что каждую секунду в течение суток приходит ровно сто запросов. К неравномерности нагрузки мы перейдём на следующей странице.

Разделяй разные типы операций

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

read_RPS  = 4,000
write_RPS =   200
total_RPS = 4,200

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

QPS — похожая величина, но контекст важен

QPS — queries per second. Термин часто используют для запросов к базе данных, поисковой системе или другому компоненту, который обрабатывает запросы в формате query. На практике RPS и QPS иногда употребляют почти как синонимы, поэтому всегда важно уточнять, что именно считается.

Один входящий HTTP-запрос не обязан превращаться в один запрос к базе данных. Он может не обращаться к ней вообще или, наоборот, выполнить несколько операций.

1 API request → 3 database queries
2,000 API RPS → about 6,000 DB QPS

Поэтому нельзя автоматически переносить RPS внешнего API на каждый внутренний компонент. Для каждого важного участка системы нужен собственный коэффициент: сколько работы он получает от одной пользовательской операции.

Начинай с пользовательских действий

Если в условии есть только число пользователей, сначала оцени частоту действий. Например, 5 миллионов активных пользователей, каждый в среднем открывает 10 страниц в день: это 50 миллионов просмотров в сутки, то есть примерно 580 средних RPS.

Дальше оценку можно уточнять отдельно для чтений, записей и внутренних обращений. Главное — сохранять цепочку от продуктового действия к технической нагрузке, а не брать RPS «из воздуха».

Всегда подписывай, какой именно RPS ты считаешь: внешний API, чтения, записи или нагрузку на конкретный внутренний компонент. Одинаковая единица не означает одинаковую работу.