Throughput (пропускная способность)

Throughput (пропускная способность) — это объём данных, который система реально передаёт или обрабатывает за единицу времени. В сетевом бенчмаркинге у термина есть более узкое определение из RFC 1242 и RFC 2544: это максимальная скорость, при которой тестовые кадры проходят без потерь.

Для практики важно не путать throughput с bandwidth и goodput. Bandwidth обычно описывает выделенный или документированный предел канала, а throughput — наблюдаемую скорость; goodput, по RFC 9065, относится к полезным данным, которыми действительно обмениваются стороны.

Английский термин: throughput. В русской практике чаще всего говорят «пропускная способность», реже оставляют английское слово без перевода. Рядом по смыслу стоят bandwidth и goodput, но это не полные синонимы.

Простыми словами

Грубо говоря, throughput можно представить как реальный темп работы трубы. На табличке может быть написано, сколько воды труба вообще способна пропустить, но вас в моменте интересует, сколько воды действительно прошло за минуту.

Та же логика работает для сети, диска и облачной VM. Паспортный максимум сам по себе ещё не означает, что вы увидите его в своём приложении: мешают потери, накладные расходы протокола, размер пакетов, число потоков, настройки драйвера и общая загруженность пути.

Как это работает

В самом общем виде throughput считают как объём переданных данных за интервал времени. RFC 9065 прямо разводит throughput и goodput: первый описывает переданные payload-данные за интервал, второй — полезные данные, которыми реально обменялись участники.

В сетевом тестировании по RFC 1242 и RFC 2544 процедура строже. Там ищут не «любую среднюю скорость», а максимальную скорость, при которой устройство под тестом не начинает терять кадры.

Источник нагрузки -> Устройство/буферы -> Канал -> Получатель
        |                    |             |
  задаём скорость      считаем потери   считаем байты
        _______________ интервал T _______________/

Throughput = объём данных за T
Для RFC 1242/2544: берём максимальную скорость, где потерь нет

1. Вы выбираете сценарий измерения: сеть или хранилище.
2. Запускаете контролируемую нагрузку на известном интервале времени.
3. Считаете, сколько данных прошло за этот интервал.
4. Проверяете контекст метрики: это payload throughput, полезный goodput или максимальная скорость без потерь.

Для дисков и блочных устройств термин обычно встречается в отчётах о bandwidth. В документации fio для этого есть метрики вроде read_bandwidth_kb и write_bandwidth_kb. Это уже не сетевой line rate и не тест RFC 1242, а скорость I/O-нагрузки на выбранном профиле чтения/записи.

Где применяется

• Сетевой бенчмаркинг устройств. RFC 1242 и RFC 2544 используются как базовая терминология и методика, когда нужно определить максимальную скорость передачи кадров без потерь.
• Облачные VM. У Amazon EC2 спецификации network bandwidth относятся и к входящему, и к исходящему трафику, но для одного потока действует ограничение 5 Gbps, если не используются cluster placement groups, MPTCP или ENA Express на подходящих инстансах. В Azure throughput измеряется в Mbps и выделяется VM для исходящего трафика; входящий трафик там не измеряется и не ограничивается напрямую. В Google Cloud максимальный исходящий bandwidth на инстанс зависит от типа машины и Tier_1 networking, не гарантирован и может снижаться из-за размера пакета, накладных расходов протокола, числа потоков, настроек драйвера и congestion.
• Облачные диски и тома. Для Amazon EBS у gp3 заявлены базовые 125 MiB/s и возможность выделить до 2,000 MiB/s; у gp2 throughput зависит от IOPS и размера I/O. Это типичный случай, где «пропускная способность» нужно читать вместе с типом носителя и профилем нагрузки.
• Инфраструктура ИИ. Термин регулярно всплывает при обсуждении загрузки моделей с открытыми весами, сетевых и дисковых узких мест в RAG и GraphRAG, а также в кластерах с TPU. В таких системах важно заранее уточнять, о каком именно throughput идёт речь: сети, хранилища или полезных данных приложения.

Практический пример

Сеть: быстрый тест через iperf3

iperf3 — инструмент для измерения сетевого throughput по TCP, UDP и SCTP. Его документация описывает модель клиент–сервер, а сервер по умолчанию слушает TCP-порт 5201.

# на принимающей стороне
iperf3 -s

# на клиенте: базовый тест к серверу
iperf3 -c 10.0.0.5

# тест в обратном направлении
iperf3 -c 10.0.0.5 -R

# машиночитаемый вывод
iperf3 -c 10.0.0.5 --json

Практический смысл такой:

1. -s поднимает сервер для измерения.
2. -c запускает клиентский тест до указанного хоста.
3. -R полезен, когда вы хотите проверить обратное направление, а не только путь «клиент → сервер».
4. --json удобно для CI, алертов и автоматического сравнения прогонов.

Важно: iperf3 — синтетический бенчмарк. По документации и репозиторию это именно измерительный инструмент, а не замена теста реального приложения. На результат влияют CPU, буферы, выбранный протокол и состояние сетевого пути.

Хранилище: проверка через fio

fio — гибкий генератор I/O-нагрузки. В его документации есть bandwidth-метрики read_bandwidth_kb и write_bandwidth_kb, по которым и судят о throughput чтения и записи.

Здесь ключевая мысль ещё важнее, чем в сети: один и тот же диск может показать разный throughput на разных job-файлах. Поэтому сначала фиксируют профиль нагрузки, а уже потом сравнивают цифры между устройствами или конфигурациями.

По состоянию на 2026-08-14 на страницах репозиториев latest release для iperf3 была iperf-3.21, а для fio — 3.42. Это динамические страницы, поэтому перед цитированием версии лучше перепроверить репозиторий.

Чем отличается от bandwidth и goodput

Ограничения и заблуждения

• Заблуждение: «throughput = bandwidth». Нет. В облачных документах bandwidth часто означает лимит или выделение, а throughput — наблюдаемую скорость. Именно поэтому паспортный максимум может не повториться в тесте.
• Заблуждение: «достаточно одного числа». Нет. В сети RFC 1242/2544 говорят о максимальной скорости без потерь, RFC 9065 — о payload и goodput, а storage-инструменты вроде fio показывают bandwidth на конкретном профиле I/O.
• Заблуждение: «синтетический тест равен продакшену». Нет. И iperf3, и fio полезны для диагностики, но результаты зависят от условий запуска и не заменяют проверку реальной рабочей нагрузки.
• Заблуждение: «облако обещало максимум — я всегда его получу». Нет. Для AWS есть отдельное замечание про предел одного потока, для Azure — особая модель измерения исходящего трафика, для Google Cloud — длинный список факторов, снижающих достижимый результат.

Редакционная оговорка. В этой статье термин разобран на материале сетей, хранилищ и облачных VM, потому что именно это подтверждено исходниками пакета. В других контекстах — например, внутри конкретного ML-фреймворка или очереди сообщений — поставщики могут использовать слово throughput иначе, поэтому числа и формулировки нужно сверять с первичной документацией.

Практический вывод: прежде чем сравнивать throughput, зафиксируйте четыре вещи: что именно измеряется, за какой интервал, при какой нагрузке и считается ли результат «полезными данными» или просто переданным объёмом.

Связанные термины и инструменты

• Open Weights (открытые веса) — когда вы переносите большие веса моделей, вопрос сетевого и дискового throughput быстро становится практическим.
• RAG — retrieval-конвейеры чувствительны к скорости обмена между хранилищем, индексом и inference-узлами.
• GraphRAG — графовые retrieval-сценарии тоже упираются в throughput на сети и дисках.
• TPU — в распределённых вычислительных системах термин часто обсуждают рядом с межузловым обменом и подачей данных.
• Инструменты для измерения: iperf3 для сети и fio для I/O. Оба инструмента полезны, но оба синтетические.

Источники

• RFC 1242: Benchmarking Terminology for Network Interconnection Devices | RFC Editor
• RFC 2544: Benchmarking Methodology for Network Interconnect Devices | RFC Editor
• RFC 9065: Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols | RFC Editor
• GitHub – esnet/iperf: iperf3: A TCP, UDP, and SCTP network bandwidth measurement tool
• iperf3.1 · esnet/iperf
• invoking.rst · esnet/iperf
• GitHub – axboe/fio: Flexible I/O Tester
• fio – Flexible I/O tester rev. 3.42 — fio 3.42-115-gcd29 documentation
• Amazon EC2 instance network bandwidth – Amazon Elastic Compute Cloud
• Amazon EBS General Purpose SSD volumes – Amazon EBS
• Azure Virtual Machine Network Throughput and Bandwidth | Microsoft Learn
• Network bandwidth | Compute Engine | Google Cloud Documentation

Вопросы и ответы

Throughput и bandwidth — это одно и то же?

Не всегда. В практической документации bandwidth часто означает выделенный или документированный предел, а throughput — реально достигнутую скорость. Из-за этого два числа нельзя механически приравнивать.

Почему я не вижу максимум, который обещает облачный провайдер?

Потому что максимум зависит от контекста. Google Cloud прямо указывает, что верхняя граница egress bandwidth не гарантирована и зависит от размера пакетов, overhead, числа потоков, драйвера и congestion; у AWS есть отдельное замечание про лимит одного потока; у Azure throughput привязан к модели измерения исходящего трафика.

Чем throughput отличается от goodput?

По RFC 9065 throughput относится к payload-данным за интервал времени, а goodput — к полезным данным, которыми реально обмениваются стороны. Поэтому goodput обычно уже и прикладнее с точки зрения конечного сервиса.

Чем измерять throughput сети и диска?

Для сети обычно используют iperf3, а для дисков и блочных устройств — fio. Но оба инструмента синтетические: их результат полезен для диагностики, а не как прямая замена продакшен-нагрузке.

Можно ли сравнивать сетевой throughput и дисковый throughput одной цифрой?

Только на очень грубом уровне и обычно не стоит. В источниках термины и методики различаются: RFC 1242/2544 описывают сетевой тест без потерь, а документация fio говорит о bandwidth-метриках на конкретном профиле I/O.