Калькулятор пропускной способности сервера

Пропускная способность сервера: полное руководство для администраторов и разработчиков

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

В этой статье мы разберём, из чего складывается пропускная способность, как её измерить, какие факторы на неё влияют и как интерпретировать результаты расчётов, полученные с помощью калькулятора выше.

Что такое пропускная способность сервера и в чём её измеряют

Пропускная способность (throughput) — это количество корректно обработанных запросов в единицу времени. Стандартная единица измерения в веб-контексте — RPS (Requests Per Second, запросов в секунду). Для сетевого оборудования метрикой выступает битрейт: мегабиты или гигабиты в секунду.

Важно не путать пропускную способность с задержкой (latency). Задержка — это время ответа на один запрос. Пропускная способность — количество запросов, которое система может обрабатывать параллельно. Система с низкой задержкой не всегда обладает высокой пропускной способностью, и наоборот. Например, сервер может отвечать за 2 мс, но при 500 одновременных соединениях задержка вырастает до 200 мс из-за переключения контекста.

Два главных ограничителя: сеть и процессор

Любой сервер имеет как минимум два аппаратных лимита: сколько данных он может передать через сетевой интерфейс и сколько вычислений выполнить за секунду. Сетевой лимит определяется шириной канала. Гигабитный порт (1000 Мбит/с) способен передать не более 125 мегабайт полезных данных в секунду, а с учётом заголовков — примерно 112–118 МБ/с.

Процессорный лимит сложнее. Один запрос может требовать парсинга JSON, обращения к базе данных, рендеринга шаблона. Если всё это занимает 10 миллисекунд на одном ядре, то одно ядро обработает не более 100 запросов в секунду. Восемь ядер дадут потолок около 800 RPS. На практике коэффициент утилизации многопоточности редко превышает 0,85 для CPU-bound задач из-за contention-эффектов и overhead'а планировщика ОС.

Как размер ответа влияет на RPS

Размер HTTP-ответа — множитель, напрямую определяющий, сколько запросов «влезет» в канал. При канале 100 Мбит/с и ответе в 100 КБ максимум составит около 110 запросов/с. Если сжать ответ gzip до 30 КБ, RPS по сети вырастает до 370 запросов/с. Это самый дешёвый способ увеличить пропускную способность — сжатие, минификация CSS/JS, оптимизация изображений.

Однако сжатие потребляет процессор. Современные алгоритмы brotli дают лучшее сжатие, но медленнее gzip на 30–50% при компрессии. Выбор между gzip и brotli — это всегда компромисс между экономией канала и загрузкой CPU. Для высоконагруженных API со стабильной нагрузкой brotli часто выигрывает. Для динамических ответов с частой инвалидацией — gzip предпочтительнее.

Роль количества ядер и архитектуры процессора

Линейное масштабирование по ядрам — миф. Реальный прирост производительности подчиняется закону Амдала: если доля последовательного кода составляет 10%, то на 16 ядрах ускорение не превысит 6,4× относительно одного ядра. В веб-приложениях последовательная часть — это работа с сокетами, синхронизация сессий, очереди ввода-вывода и блокировки в рантайме языка.

Высокая тактовая частота ядра (3,5+ ГГц) даёт больший прирост для одного потока, чем добавление ядер с низкой частотой. Для типичного PHP-FPM или Node.js приложения 4 быстрых ядра часто эффективнее, чем 12 медленных. Калькулятор использует усреднённый коэффициент 0,85, но для вашего конкретного стека имеет смысл провести бенчмарк и подставить эмпирический множитель.

Практическое применение расчётов при планировании

Допустим, вы запускаете сервис доставки еды и ожидаете 10 000 одновременных пользователей в пике, каждый из которых делает 0,3 запроса в секунду (просмотр каталога, корзина, оформление). Суммарная ожидаемая нагрузка — 3 000 RPS. Средний размер JSON-ответа от API — 8 КБ. Время обработки — 15 мс на ядро.

Калькулятор покажет, что для такой нагрузки нужен канал не менее 192 Мбит/с и минимум 53 ядра (с учётом коэффициента 0,85). Это означает, что одного сервера недостаточно — потребуется кластер из 4–6 машин или переход на CDN с кэшированием на краю. Без предварительного расчёта вы бы узнали об этом в момент отказа сервера под нагрузкой.

Мониторинг и валидация расчётов

Теоретические цифры необходимо проверять. Нагрузочное тестирование инструментами wrk, locust или k6 на staging-окружении даёт реальные кривые зависимости задержки от RPS. Сравните точку перегиба на графике с предсказанным значением. Если реальный предел на 25% ниже — ищите узкое место в коде, сетевых настройках или конфигурации ОС.

Полезные системные метрики для мониторинга: `netstat -s` для статистики TCP, `ss -tiepm` для очередей сокетов, `mpstat` для утилизации ядер, `nicstat` для сетевых интерфейсов. В совокупности эти данные позволяют построить точную модель производительности вашего сервера и вовремя заметить деградацию до того, как она станет проблемой для пользователей.

Заключение

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