Пропускная способность сервера: расчёт нагрузки

Пропускная способность сервера — это максимальное количество обработанных запросов за единицу времени (обычно секунда), при котором качество обслуживания остаётся приемлемым: время ответа не превышает заданного порога (например, 1 секунда), ошибки HTTP 5xx отсутствуют.

Если вы разрабатываете веб-приложение, API или стриминговый сервис, без этой метрики вы рискуете:

• переплатить за избыточные ресурсы VPS/облачного сервера,
• провалить запуск или рекламную кампанию из-за падения при нагрузке,
• неправильно задать SLA для клиентов.

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

Важно: пропускная способность не равна ширине канала (скорости сети). Это количество операций сервера, а не трафик в Мбит/с.

Базовая формула для веб-сервера с асинхронной моделью (например, nginx, Node.js, Go):

Она исходит из закона Литтла: L = λW, где L — число запросов в системе, λ — интенсивность (RPS), W — среднее время обработки. На практике ограничивающим фактором становится CPU/IO, а не только сеть.

• Средняя задержка — время от получения запроса до начала ответа (latency). Включает обработку в приложении, запросы к БД, рендеринг, но не время на передачу по сети.
• Число одновременных соединений — зависит от модели воркеров. Для Node.js с одним потоком это обычно 1000-2000 на ядро; для многопоточного Python — 10-50 на воркер.

Пример: если средняя задержка 200 мс (0.2 с) и сервер держит 200 одновременных соединений, то RPS ≈ 200 / 0.2 = 1000. Реальный максимум будет чуть ниже из-за накладных расходов (очереди, контекстные переключения).

Для детального расчёта ресурсов под конкретный проект попробуйте Калькулятор нагрузки на сервер.

Допустим, у вас интернет-магазин на WordPress + MySQL, средний пользователь делает 5 запросов за сессию, дневная нагрузка — 5000 активных сессий, пик в час 300 сессий. Нужно оценить минимальный сервер.

1. Считаем среднее число запросов в секунду (RPS):
   300 сессий/час × 5 запросов / 3600 с ≈ 0.42 RPS — пиковая нагрузка в секунду. Это почти ничего, даже дешёвый VPS справится.
2. Но на практике WordPress генерирует много медленных запросов из-за PHP + MySQL. Реальная средняя задержка на дешёвом хостинге — 500-1000 мс. При 300 параллельных соединениях maximum RPS будет 300 / 0.5 = 600 RPS, то есть запас есть.
3. Проблема в том, что WordPress может открывать соединения к БД на каждый запрос. Если БД не выдерживает 300 одновременных соединений, наступает блокировка.

В итоге для такого магазина достаточно сервера с 2 vCPU, 4 GB RAM (около 1500 руб./мес. в 2026). Но если вы используете PHP-FPM с 50 воркерами, то максимальная пропускная способность будет около 50 / 0.5 = 100 RPS. Для пика в 0.42 RPS — огромный запас. Зная это, можно смело брать минимальную конфигурацию.

Проверить стоимость подходящего сервера можно в Калькуляторе стоимости VPS сервера.

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

Важно: тестируйте на нагрузке, близкой к реальной (пропорция чтения/записи, размер данных). Чистый GET без тела даёт завышенные RPS.

После теста смотрите на p95 latency (95% запросов быстрее этого времени) и error rate. Если error rate > 1% или p95 > 1 секунды — пропускная способность превышена.

• Игнорирование бэкенда: считают только сетевую пропускную способность (10 Гбит/с), забывая про CPU и БД. Пример: сервер отдаёт статику на 1000 RPS, но динамический запрос к БД идёт 200 мс, снижая RPS до 30.
• Путаница между параллельными и последовательными запросами: браузер может открыть 6 соединений к домену, а сервер — обрабатывать 200 параллельно. Не смешивайте.
• Неучёт keep-alive: HTTP/2 multiplexing позволяет использовать одно соединение для многих запросов, что резко увеличивает RPS без роста числа соединений.
• Тестирование на localhost: задержка сети (1-30 мс) добавляется к латентности. Всегда тестируйте с реальным сетевым расстоянием.
• Завышение ожиданий от дешёвого VPS: на 1 vCPU (до 2.5 ГГц) реальный RPS для Python/Django редко превышает 20-30 на динамику. Для Go или Node.js — 200-400.

Проверить свои знания по архитектуре серверов можно в Тесте на когнитивные способности (раздел технического мышления).

API (JSON): обычно лёгкие ответы (1-5 КБ), узким местом становится шина CPU/сеть при большом числе запросов. Типичная формула: RPS = (кол-во воркеров × 1000) / (latency + сериализация). Для FastAPI/Node.js — до 5000 RPS на 2 vCPU.

Стриминг видео (RTMP/HLS): здесь метрика — битрейт, а не RPS. Один стрим 5 Мбит/с занимает 5 Мбит/с пропускной способности сети. 1000 одновременных стримов = 5 Гбит/с. Серверный CPU в основном отвечает за репакинг/транскодинг.

Базы данных: пропускная способность измеряется в QPS (queries per second). Она сильно зависит от кэширования. InnoDB в MySQL на одном SSD может давать ~1000 QPS на простые SELECT, а 10 000 — на закэшированные.

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

Таблица ниже показывает типичные цифры для сервера среднего уровня (2 vCPU, 4 GB RAM, SSD) на 2026 год при тестировании через nginx + PHP-FPM или Node.js.

Разница колоссальная. Поэтому для проекта с преобладающей динамикой критично кэширование (Redis, CDN) и выбор языка.