Requests Per Minute (RPM)

Requests Per Minute (RPM) или «запросы в минуту» — это базовая метрика в IT и веб-разработке, показывающая суммарное количество обращений, которые сервер, приложение или API получает и обрабатывает за одну минуту.

Что такое RPM и почему это важно?

В мире веб-разработки, системного администрирования и создания облачных сервисов понимание нагрузки на систему является критически важным фактором. Метрика RPM помогает разработчикам и владельцам бизнеса оценить, насколько активно пользователи или сторонние программы взаимодействуют с их цифровым продуктом. Эта единица измерения является золотой серединой для оценки трафика: она более показательна для бизнес-логики, чем запросы в секунду (RPS), и более детализирована, чем запросы в час.

Мониторинг этого показателя позволяет решать сразу несколько стратегических задач:

• Предотвращение сбоев (Downtime): Если показатель RPM резко возрастает в десятки раз, сервер может исчерпать свои ресурсы (процессорное время, оперативную память) и «упасть». Постоянный контроль позволяет вовремя заметить аномалию.
• Масштабирование инфраструктуры: Понимая средний и пиковый RPM, DevOps-инженеры могут настраивать автоскейлинг — автоматическое добавление новых серверов в часы пик и их отключение ночью для экономии бюджета.
• Тарификация и ограничение доступа (Rate Limiting): Практически все современные SaaS-платформы и коммерческие API продают доступ к своим данным, базируясь на лимитах запросов в минуту.
• Выявление кибератак: Аномальный всплеск RPM с одного IP-адреса часто свидетельствует о попытке агрессивного парсинга данных, брутфорсе (подборе паролей) или начинающейся DDoS-атаке.

Чем RPM отличается от RPS?

Часто новички путают RPM с другой популярной метрикой — RPS (Requests Per Second, запросы в секунду). Хотя суть у них одинаковая, применяются они в разных контекстах. RPS используется для оценки производительности высоконагруженных систем (Highload), где счет идет на тысячи операций в одно мгновение. RPM же чаще применяется для оценки работы API, фоновых задач (cron jobs), лимитов для пользователей или аналитики посещаемости сайтов со средним трафиком.

Примеры использования RPM в реальной жизни

С метрикой Requests Per Minute мы сталкиваемся гораздо чаще, чем может показаться на первый взгляд. Вот несколько наглядных примеров того, как она работает на практике:

1. Использование нейросетей и API

Если вы когда-либо интегрировали в свои проекты современные нейросети (например, от OpenAI, Google или Anthropic), вы наверняка видели ограничения в документации. Бесплатный тариф (Free Tier) может ограничивать вас до 3 RPM. Это значит, что вы можете отправить только 3 промпта в минуту. Для корпоративных клиентов этот лимит может составлять 10 000 RPM и более, что позволяет обслуживать тысячи пользователей одновременно.

2. Работа интернет-магазина в период распродаж

Представьте классический интернет-магазин. В обычный будний день он обрабатывает около 100-200 RPM — пользователи неспешно листают каталог, добавляют товары в корзину, оформляют заказы. Но в день старта «Черной пятницы» запускается масштабная email-рассылка. Нагрузка мгновенно возрастает до 5 000 RPM. Если база данных и веб-серверы не рассчитаны на такой скачок, сайт просто перестанет открываться, выдавая ошибку 502 Bad Gateway.

3. Интеграция с платежными шлюзами

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

Интересный факт: Как появился код ошибки 429

Когда вы превышаете допустимый лимит RPM, сервер обычно прерывает обработку и возвращает вам HTTP-статус 429 Too Many Requests («Слишком много запросов»). Но мало кто знает, что этот статус не входил в изначальную спецификацию HTTP, созданную Тимом Бернерсом-Ли в начале 90-х годов.

В первые годы существования интернета разработчики использовали статус 503 Service Unavailable или даже 400 Bad Request, чтобы отбиваться от назойливых ботов и слишком частых обращений. Это создавало огромную путаницу: код 503 означает проблему на стороне сервера, хотя виноват был клиент, отправляющий слишком много запросов. Лишь в 2012 году, когда API стали основой современного интернета, а необходимость жестко контролировать RPM стала критической для бизнеса, был официально принят стандарт RFC 6585. Он ввел статус 429, который теперь является универсальным языком общения между серверами. Он буквально означает: «Остановись, ты превысил свой лимит RPM, попробуй позже!»