Кратко

  • RFC 9971 описывает Multiple Loss Ratio Search: лабораторную методику, которая ищет одну или несколько объявленных целей по доле потерь и сообщает границы для каждой цели при заданных системе и трафике.
  • Условная пропускная способность свидетельствует о процедуре — границе SUT, профиле, нагрузке, длительности и цели, — а не о гарантированной ёмкости, приложении, SLA или обязательстве поставщика.
  • Чтобы использовать число для production, договора или закупки, нужны отдельные наблюдения реальной среды и локальное решение с владельцем, сроком и откатом.

Число имеет смысл только вместе с постановкой опыта

RFC 9971 называет метод Multiple Loss Ratio Search, или MLRsearch. Его задача — сделать тесты плоскости данных более повторяемыми и сопоставимыми, а поиск — короче, в том числе для программных сетевых функций на обычных серверах. Документ не обещает найти неизменную «скорость продукта». Он задаёт способ проводить Trials с выбранными нагрузками и длительностями для явно сформулированных Search Goals.

Поэтому результат — не голая скорость. Для сравнения нужны SUT, которому предъявлялся стимул, профиль и направление трафика, размеры кадров, предложенная нагрузка, длительность Trial, разрешённая доля потерь и заявленная ширина границ. Если убрать эти поля, измерение не становится проще: оно превращается в утверждение, которое нельзя ни воспроизвести, ни опровергнуть.

RFC 9971 имеет статус Informational. Термины BCP 14 задают точность для процедуры, заявляющей соответствие MLRsearch; они не требуют внедрения и не подтверждают ни один продукт. Метод независим от RFC 2544, не изменяет и не отменяет его. Конкретный одноцелевой сценарий можно настроить в соответствии с RFC 2544, но это свойство описанной процедуры и отчёта, а не автоматический эффект ссылки на RFC 9971.

Испытывается не только функция

RFC различает DUT и SUT. DUT — интересующая нас функция пересылки или устройство. SUT — вся совокупность, которой предложен трафик и от которой измеряется ответ. Для программной функции в SUT могут входить хост, firmware, ОС, hypervisor, драйверы, NIC, I/O и соседние нагрузки. Один и тот же бинарный файл способен дать другой Trial, когда меняется окружающая система.

Словом noise RFC объединяет внешние помехи SUT и внутренние колебания функции, которые нельзя надёжно развести. Планирование CPU, давление памяти или I/O, соседняя задача и собственная обработка могут проявиться как потеря. Конечная серия опытов не устанавливает окончательную причину каждого кадра. Метод лишь заставляет описывать испытания и их границы честно.

Отсюда следует граница доказательства. Бенчмарк может говорить о заявленном SUT в заявленном состоянии. Он не доказывает вне контекста неизменное свойство программы и тем более не доказывает ёмкость работающего сервиса с переменными маршрутами, повторными попытками, политиками клиентов, зависимостями и авариями.

Цели по потерям показывают, где сделан выбор

RFC 1242 определяет throughput как максимальную скорость без потери любого предложенного кадра. Это полезная строгая точка. Но у границы программной системы результаты могут быть несогласованны: Trial с большей нагрузкой иногда показывает меньшую долю потерь, чем предшествующий Trial. Один итоговый показатель скрывает, кто выбрал длительность, точность и способ обращения с таким расхождением.

MLRsearch делает роли явными. Manager готовит сущности и Test Report; Controller выбирает нагрузки и длительности; Measurer выполняет Trials. Это концептуальные роли, а не обязательство иметь три продукта. У каждого Search Goal есть собственные условия; для регулярного результата relevant lower bound и relevant upper bound сходятся с указанной goal width.

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

Повторяемость не делает лабораторию представительной

Повторяемый опыт полезен для поиска небольшой регрессии в фиксированной среде. Он может столь же аккуратно повторять профиль, который не похож на production. RFC 9971 оставляет внутренние эвристики выбора нагрузки Controller реализации и не задаёт всеобщую конфигурацию целей. Это не место для рекламного заполнения, а место, где оператор обязан назвать гипотезу и риск.

Running-Code Primacy Хэн Лу даёт практическое правило: главны исполняемый код, действующая конфигурация, реально предложенный трафик и сырая запись, а не престиж слова «бенчмарк». Общая методика облегчает обмен отчётами, но не передаёт её автору право выбирать проданную ёмкость, допустимую потерю или действие другой стороны.

Постройте отдельный мост к обязательству

Нужны четыре разных записи. Benchmark record хранит сборку, границу оборудования и виртуализации, профиль, цели, длительности, инструменты и сырые результаты. Interpretation record формулирует только узкий вывод, например отсутствие регрессии относительно лабораторной базы. Production evidence хранит очереди, CPU, I/O, retries, транзакции и service canary в реальном объёме. Decision record называет того, кто одобряет release, закупку, резерв ёмкости или rollback, а также пороги, исключения и срок.

Бенчмарк может быть входом в закупку, но не заменяет приёмочную нагрузку и договор. Он может помогать планировать мощность, но не заменяет распределение пиков, запас на отказ и конкуренцию нагрузок. Он может участвовать в release gate, но не заменяет совместимость, безопасность, поэтапное развёртывание и возврат. SLA — обещание о конкретной услуге на конкретный период, а не воспоминание о хорошем опыте с кадрами.

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

Источники