Rss load balancing profile что это

Выбор сетевого адаптера

область применения: Windows server 2022, Windows server 2019, Windows Server 2016, Azure Stack хЦи, версии 21H2 и 20H2

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

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

Параметры сетевого адаптера можно настроить с помощью Windows PowerShell. Дополнительные сведения см. в разделе командлеты сетевого адаптера в Windows PowerShell.

Возможности разгрузки

Разгрузка задач из центрального процессора в сетевой адаптер может снизить загрузку ЦП на сервере, что повышает общую производительность системы.

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

Масштабирование на стороне приема

Windows Server 2016, Windows Server 2012, Windows Server 2012 R2, Windows server 2008 r2 и Windows server 2008 поддерживают масштабирование на стороне приема (RSS).

Некоторые серверы настроены с несколькими логическими процессорами, которые используют ресурсы оборудования (например, физические ядра) и обрабатываются как одновременные однопотоковые (SMT) одноранговые узлы. Примером является технология Intel Hyper-Threading. RSS направляет сетевую обработку до одного логического процессора на ядро. Например, на сервере с технологией Intel Hyper-Threading, 4 ядрами и 8 логическими процессорами RSS использует не более 4 логических процессора для сетевой обработки.

RSS распределяет входящие сетевые операции ввода-вывода между логическими процессорами, чтобы пакеты, входящие в одно и то же подключение TCP, обрабатывались на одном логическом процессоре, который сохраняет порядок.

Кроме того, RSS-адрес балансировки нагрузки распределяет трафик UDP и многоадресную рассылку, а также направляет связанные потоки (определяемые путем хэширования адресов источника и назначения) на один и тот же логический процессор, сохраняя порядок связанных прибытий. Это помогает повысить масштабируемость и производительность для сценариев, требующих интенсивного получения, для серверов с меньшим числом сетевых адаптеров, чем для соответствующих логических процессоров.

Настройка RSS

в Windows Server 2016 можно настроить RSS с помощью командлетов Windows PowerShell и профилей RSS.

профили RSS можно определить с помощью параметра – Profile командлета Set-нетадаптеррсс Windows PowerShell.

Windows PowerShell команды для настройки RSS

Следующие командлеты позволяют просматривать и изменять параметры RSS для каждого сетевого адаптера.

Подробную справочную информацию по командам для каждого командлета, включая синтаксис и параметры, можно получить, щелкнув следующие ссылки. кроме того, имя командлета можно передать команде Get-Help в Windows PowerShell запросе для получения подробных сведений по каждой из команд.

Disable-нетадаптеррсс. Эта команда отключает RSS на указанном сетевом адаптере.

Enable-нетадаптеррсс. Эта команда включает RSS на указанном сетевом адаптере.

Get-нетадаптеррсс. Эта команда получает свойства RSS указанного сетевого адаптера.

Set-нетадаптеррсс. Эта команда задает свойства RSS для указанного сетевого адаптера.

Профили RSS

Можно использовать параметр – Profile командлета Set-NetAdapterRss, чтобы указать, какие логические процессоры назначены сетевому адаптеру. Для этого параметра доступны следующие значения:

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

Клосестстатик. Предпочтительными являются номера логических процессоров рядом с базовым обработчиком RSS сетевого адаптера. В этом профиле операционная система не перераспределяет логические процессоры динамически в зависимости от нагрузки.

NUMA. Номера логических процессоров обычно выбираются на разных узлах NUMA для распределения нагрузки. В этом профиле операционная система может динамически распределять логические процессоры в зависимости от нагрузки.

Нумастатик. Это профиль по умолчанию. Номера логических процессоров обычно выбираются на разных узлах NUMA для распределения нагрузки. В этом профиле операционная система не будет динамически распределять логические процессоры в зависимости от нагрузки.

Консервативный. RSS использует как можно меньше процессоров, чтобы поддерживать нагрузку. Этот параметр позволяет сократить количество прерываний.

в зависимости от сценария и характеристик рабочей нагрузки можно также использовать другие параметры командлета Set-нетадаптеррсс Windows PowerShell, чтобы указать следующее:

* Макспроцессорс: задает максимальное число используемых обработчиков RSS. Это гарантирует, что трафик приложения будет привязан к максимальному количеству процессоров на данном интерфейсе. Пример синтаксиса:

Set-NetAdapterRss –Name «Ethernet» –MaxProcessors

* Басепроцессорграуп: задает базовую группу процессоров узла NUMA. Это влияет на массив процессоров, используемый RSS. Пример синтаксиса:

Set-NetAdapterRss –Name «Ethernet» –BaseProcessorGroup

* Макспроцессорграуп: задает максимальную группу процессоров для узла NUMA. Это влияет на массив процессоров, используемый RSS. Установка этого параметра ограничивает максимальную группу процессоров, чтобы балансировка нагрузки была согласована в k-группе. Пример синтаксиса:

Set-NetAdapterRss –Name «Ethernet» –MaxProcessorGroup

* Басепроцессорнумбер: задает номер базового процессора узла NUMA. Это влияет на массив процессоров, используемый RSS. Это позволяет секционировать процессоры между сетевыми адаптерами. Это первый логический процессор в диапазоне процессоров RSS, назначенных каждому адаптеру. Пример синтаксиса:

Set-NetAdapterRss –Name «Ethernet» –BaseProcessorNumber

* NumaNode: узел NUMA, из которого каждый сетевой адаптер может выделить память. Это может быть в k-группе или из разных k-групп. Пример синтаксиса:

Set-NetAdapterRss –Name «Ethernet» –NumaNodeID

* Нумберофрецеивекуеуес. Если логические процессоры будут недостаточно загружены для приема трафика (например, в диспетчере задач), можно попробовать увеличить число очередей RSS со значения по умолчанию 2 до максимального, поддерживаемого сетевым адаптером. Сетевой адаптер может иметь параметры для изменения числа очередей RSS в составе драйвера. Пример синтаксиса:

Set-NetAdapterRss –Name «Ethernet» –NumberOfReceiveQueues

Для получения дополнительных сведений щелкните следующую ссылку, чтобы скачать масштабируемые сети: устранение узких мест обработки приема — RSS-канал в формате Word.

Общие сведения о производительности RSS

Настройка RSS требует понимания конфигурации и логики балансировки нагрузки. чтобы убедиться, что параметры RSS вступили в действие, можно просмотреть выходные данные при выполнении командлета Get-нетадаптеррсс Windows PowerShell. Ниже приведен пример выходных данных этого командлета.

В дополнение к параметрам, которые были заданы, ключевым аспектом выходных данных является выход таблицы косвенного обращения. В таблице косвенных обращений отображаются контейнеры хэш-таблиц, которые используются для распределения входящего трафика. В этом примере нотация н:к обозначает пару индексов NUMA K-Group: CPU, которая используется для направления входящего трафика. Мы увидим ровно две уникальные записи (0:0 и 0:4), которые представляют собой k-Group 0/CPU0 и k-Group 0/CPU 4 соответственно.

Источник

Масштабирование на стороне приема для сетевых адаптеров Intel®

Тип материала Установка и настройка

Идентификатор статьи 000006703

Последняя редакция 31.01.2020

При включении масштабирования на стороне приема (RSS) все приемы обработки данных для конкретного TCP-подключения используются несколькими процессорами или ядрами процессора. Без RSS все процессы обработки данных выполняются одним процессором, что приводит к неэффективному использованию кэша системы.

Конфигурация RSS-канала

Поддержка RSS доступна на вкладке «Дополнительно» окна свойств адаптера. Если ваш адаптер или операционная система не поддерживают RSS-канал, Настройка RSS не отображается.

Сотрудничество

Известные проблемы

В ОС Windows Server 2012 * Настройка RSS для ближайших процессоров может привести к сбоям при передаче и получении

Неисправное подключение и возможна нестабильность системы

Если в вашей системе установлены сетевые устройства, отличные от Intel, которые поддерживают масштабирование на стороне заказчика, ключевое слово рссбасекпу могло быть изменено со значения по умолчанию, равного 0x0, для указания логического процессора. Если это ключевое слово было изменено, устройства, основанные на контроллерах Intel® 82598 или 82599 10 Gigabit Ethernet, могут не передавать трафик. Попытка внести изменения в драйвер в этом состоянии может привести к нестабильной работе системы. Присвойте параметру Рссбасекпу значение 0x0 или значение, соответствующее физическому процессору, и перезагрузите систему, чтобы устранить проблему.

Значение масштабирования «получение стороны» пусто

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

Использование ЦП выше ожидаемого

Установка для очередей RSS большего размера, чем 4, рекомендуется только для крупных веб-серверов с несколькими процессорами. Значения выше 4 могут привести к увеличению использования ЦП до неприемлемых уровней и другим негативным последствиям для производительности системы.

Источник

Повышение пропускной способности сетевых интерфейсов для SQL Server с помощью настройки параметров RSS

Недавно автор работал с партнёром над тестированием возможностей масштабирования сетевой нагрузки SQL Server. В тестах использовался сервер DL980 с 8 процессорными сокетами, которые представляли системе 80 физических ядер, и управлялось всё это операционной системой Windows 2008 R2 sp1. В распоряжении SQL Server было 4 сетевых карты производительностью 1Gbps, они поддерживали сетевой трафик между SQL Server и серверами приложений. К удивлению автора, максимальная загрузка во время теста наблюдалась только на 2-х из 80-ти процессорных ядер, и практически вся эта нагрузка приходилась на привилегированный режим работы процессоров (privileged/DPC % time). Известно, что Windows 2008 R2 по умолчанию использует до 4-х процессорных ядер для управляющих модулей, относящихся к RSS (см. упомянутую выше статью). Почему же в данном случае использовалось только 2 процессора? Стоит отметить, что то время, которое процессоры работали в привилегированном режиме, могло относиться к деятельности драйверов устройств, таких как сетевое оборудование и драйверы системы хранения данных. Воспользовавшись входящим в комплект Windows SDK инструментом XPerf, можно проследить работу подобных устройств на уровне драйверов и выявить основного потребителя привилегированного режима процессоров. В данном случае, большая часть этого режима использовалась для обслуживания драйвера сетевых устройств NDIS.sys.

Подозревая, что описанное выше поведение могло проявиться в Windows ошибочно, автор явным образом задал значение для ключа реестра HLKM\System\CurrentControlSet\Services\Ndis\Parameters, установив параметру MaxNumRssCpus значение 8 (подробности об этом ключе можно найти в упомянутом выше статье), в надежде, что эта установка позволит привлечь дополнительные процессоры, для обслуживания прерываний, связанных с передаваемыми по сети пакетами. Но, эта настройка никак не повлияла на число используемых процессоров. Автор обратился за консультациями к коллегам в Windows Networking Team, с просьбой помочь решить эту проблему. Пока ответ ещё не был получен, была предпринята попытка подключить серверы приложений используя все 4 сетевые платы (серверы приложений были поделены равномерно по количеству сетевых карт, каждая группа серверов подключается только к одному IP-адресу). К всеобщей радости, большой процент привилегированной нагрузки теперь наблюдался на 8ми ядрах.

В итоге, в качестве решения проблемы был избран вариант с масштабированием сетевой нагрузки, когда использовались 4 сетевые платы со своими IP адресами. Это позволило получить нужную пропускную способность сетевых интерфейсов, и обеспечить обслуживание RSS таким числом процессоров, которое позволило эффективно обслужить большой сетевой трафик. Конечно, можно использовать более производительные сетевые платы 10Gbps, но при этом следует обязательно задавать правильные значения для «RSS rings».

В качестве резюме можно выделить два основных момента в настройке RSS для обслуживания нагрузки SQL Server с большим сетевым трафиком:

Настройте в Windows максимальное число задействованных для RSS процессоров («starting RSS CPU») руководствуясь рекомендациями в статье: Receive-Side Scaling Enhancements in Windows Server 2008
Для каждой используемой сетевой платы задайте значения «RSS Rings» («RSS Queues») таким образом, чтобы сумма этих значений для всех сетевых плат соответствовала значению MaxNumRssCpu в реестре Windows. Учтите, что максимально возможное значение у разных производителей плат может отличаться. Чтобы обеспечить необходимую производительность обслуживания большого трафика по сети, возможно, придётся обновить драйвера/firmware или установить дополнительные сетевые платы.

Источник

Настройка производительности сетевых адаптеров

область применения: Windows server 2022, Windows server 2019, Windows Server 2016, Azure Stack хЦи, версии 21H2 и 20H2

используйте сведения в этом разделе для настройки сетевых адаптеров производительности для компьютеров под управлением Windows Server 2016 и более поздних версий. Если сетевые адаптеры предоставляют параметры настройки, эти параметры можно использовать для оптимизации пропускной способности сети и использования ресурсов.

Правильные параметры настройки для сетевых адаптеров зависят от следующих переменных.

В следующих разделах описывается ряд параметров настройки производительности.

Включение функций разгрузки

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

Не используйте разгрузку задач IPSec функции разгрузки или разгрузку TCP Chimney. эти технологии являются устаревшими в Windows Server 2016 и могут негативно сказаться на производительности сервера и сети. Кроме того, эти технологии могут не поддерживаться корпорацией Майкрософт в будущем.

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

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

Включение масштабирования на стороне приема (RSS) для веб-серверов

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

Избегайте использования сетевых адаптеров, отличных от RSS, и сетевых адаптеров, поддерживающих RSS, на одном сервере. Из-за логики распределения нагрузки в RSS и протоколе HTTP, производительность может быть значительно снижена, если сетевой адаптер, не поддерживающий RSS, принимает веб-трафик на сервере с одним или несколькими сетевыми адаптерами, поддерживающими RSS. В этом случае необходимо использовать сетевые адаптеры, поддерживающие RSS, или отключить RSS на вкладке Дополнительные свойства в свойствах сетевого адаптера.

Чтобы определить, поддерживает ли сетевой адаптер RSS, можно просмотреть сведения RSS на вкладке Дополнительные свойства в свойствах сетевого адаптера.

Профили RSS и очереди RSS

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

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

Увеличение ресурсов сетевого адаптера

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

В некоторых сетевых адаптерах устанавливаются небольшие буферы приема для экономии выделенной памяти от узла. Это ведет к потере пакетов и снижению производительности. Поэтому для сценариев с интенсивным приемом рекомендуется увеличить буфер приема до максимума.

Если сетевой адаптер не предоставляет настройки ресурсов вручную, он динамически настраивает ресурсы, или для ресурсов задано фиксированное значение, которое нельзя изменить.

Включение контроля прерываний

Для управления прерываниями прерываний некоторые сетевые адаптеры предоставляют различные уровни управления прерываниями, различные параметры объединения буфера (иногда отдельно для буферов отправки и получения) или и то, и другое.

Следует рассмотреть возможность контроля прерываний для рабочих нагрузок, привязанных к ЦП. При использовании управления прерываниями учитывайте компромисс между экономией ЦП узла и задержкой, а также увеличением экономии ресурсов узла из-за большего количества прерываний и снижения задержки. Если сетевой адаптер не выполняет контроль прерываний, но он предоставляет объединение буферов, можно повысить производительность, увеличив число Объединенных буферов, чтобы освободить больше буферов на отправку или получение.

Настройка производительности для обработки пакетов с низкой задержкой

Многие сетевые адаптеры позволяют настраивать параметры для оптимизации системной задержки. Задержка — это время между обработкой входящего пакета сетевым драйвером и отправкой этого пакета обратно. Обычно это время измеряется в микросекундах. Для сравнения время передачи пакетов на длинные дистанции обычно измеряется в миллисекундах (это на порядок дольше). Эта настройка не сокращает время прохождения пакета.

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

Установите в операционной системе профиль управления электропитанием Высокая производительность.

Этот параметр не работает должным образом, если BIOS системы имеет значение отключить управление питанием в операционной системе.

Включить статические разгрузки. Например, включите контрольные суммы UDP, контрольные суммы TCP и отправку параметров большой разгрузки (LSO).

Если трафик проходит через несколько потоков, например при получении многоуровневого трафика многоадресной рассылки, включите RSS.

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

Обрабатывайте прерывания сетевого адаптера и DPC на основном процессоре, который совместно использует процессорный кэш с ядром, которое используется программой (пользовательским потоком), обрабатывающей пакет. Для передачи процесса конкретным логическим процессорам можно использовать настройку фиксации ЦП вместе с настройкой RSS. Использование одного ядра для прерываний, DPC и пользовательского потока ведет к снижению производительности из-за увеличения нагрузки, поскольку ISR, DPC и поток будут конкурировать за ядро.

Прерывания управления системой

Многие аппаратные системы используют прерывания управления системой (SMI) для различных функций обслуживания, таких как сообщения об ошибках с кодом коррекции ошибок (ECC), поддержка устаревшей совместимости с USB, управление вентилятором и управление параметрами питания, управляемой BIOS.

SMI — это прерывание с наивысшим приоритетом в системе и помещает ЦП в режим управления. Этот режим загружает все остальные действия, в то время как SMI запускает подпрограммы службы прерываний, обычно содержащиеся в BIOS.

К сожалению, такое поведение может привести к скачкам задержки 100 микросекунд или более.

Когда необходимо обеспечить минимальную задержку, следует запросить у поставщика оборудования версию BIOS, в которой прерывания SMI имеют наименьший возможный приоритет. Эти версии BIOS часто называются «BIOS с низкой задержкой» или «SMI Free BIOS». В некоторых случаях аппаратная платформа не может полностью исключить активность SMI, так как она используется для управления важными функциями (например, вентиляторами).

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

Настройка производительности TCP

Для настройки производительности TCP можно использовать следующие элементы.

Автоматическая настройка окна приема TCP

в более ранних версиях Windows сетевой стек Windows использовал окно приема фиксированного размера (65 535 байт), которое ограничивает общую возможную пропускную способность для подключений. Общая пропускная способность подключений TCP может ограничивать сценарии использования сети. Автоматическая настройка окна приема TCP позволяет этим сценариям полностью использовать сеть.

Для окна приема TCP, имеющего определенный размер, можно использовать следующее уравнение для вычисления общей пропускной способности отдельного соединения.

Общая пропускная способность в байтах Размер окна приема TCP в байтах * (1/ Задержка подключения в секундах)

Например, для соединения с задержкой 10 мс общая пропускная способность составляет только 51 Мбит/с. Это значение целесообразно для большой корпоративной сетевой инфраструктуры. Однако с помощью автонастройки для настройки окна приема подключение может обеспечить полную скорость линии для подключения 1 Гбит/с.

Некоторые приложения определяют размер окна приема TCP. Если приложение не определяет размер окна приема, скорость связи определяется следующим образом:

Например, на компьютере с установленным сетевым адаптером с 1 Гбит/с размер окна должен быть 64 КБ.

Эта функция также обеспечивает полное использование других функций для повышения производительности сети. Эти функции включают остальные параметры TCP, определенные в RFC 1323. используя эти функции, компьютеры на базе Windows могут согласовать размеры окна приема TCP, которые меньше, но масштабируются по определенному значению в зависимости от конфигурации. Такое поведение упрощает обработку размеров для сетевых устройств.

Может возникнуть проблема, при которой сетевое устройство не соответствует параметру TCP Window Scale, как определено в RFC 1323 и, следовательно, не поддерживает коэффициент масштабирования. в таких случаях обратитесь к этой статье KB 934430, если вы пытаетесь использовать Windows Vista за устройством брандмауэра или обратитесь в службу поддержки для поставщика сетевых устройств.

Проверка и настройка уровня автонастройки окна приема TCP

для просмотра или изменения уровня автонастройки окна приема TCP можно использовать команды netsh или командлеты Windows PowerShell.

в отличие от версий Windows, которые предварительно устарели Windows 10 или Windows Server 2019, вы больше не можете использовать реестр для настройки размера окна приема TCP. Дополнительные сведения об устаревших параметрах TCPсм. здесь.

Подробные сведения о доступных уровнях автонастройки см. в разделе уровни автонастройки.

Использование команды Netsh для просмотра или изменения уровня автонастройки

Чтобы проверить текущие параметры, откройте окно командной строки и выполните следующую команду:

Выходные данные этой команды должны выглядеть следующим образом:

Чтобы изменить этот параметр, выполните в командной строке следующую команду:

В предыдущей команде представляет новое значение для уровня автоматической настройки.

Использование PowerShell для просмотра или изменения уровня автонастройки

Чтобы проверить текущие параметры, откройте окно PowerShell и выполните следующий командлет.

Выходные данные этого командлета должны выглядеть следующим образом.

Чтобы изменить этот параметр, выполните следующий командлет в командной строке PowerShell.

В предыдущей команде представляет новое значение для уровня автоматической настройки.

Дополнительные сведения об этих командлетах см. в следующих статьях:

Уровни автонастройки

Можно настроить автоматическую настройку окна приема на любой из пяти уровней. Уровень по умолчанию — Обычная. В следующей таблице описаны уровни.

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

Уровень автонастройки: нормальный (состояние по умолчанию)

Уровень автонастройки: отключен

Уровень автонастройки: ограниченный

Уровень автонастройки: очень ограниченный

Уровень автонастройки: экспериментальный

Устаревшие параметры TCP

следующие параметры реестра из Windows Server 2003 больше не поддерживаются и не учитываются в более поздних версиях.

Все эти параметры были расположены в следующем подразделе реестра:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Платформа фильтрации Windows

Windows в Vista и Windows Server 2008 появилась платформа фильтрации Windows (WFP). WFP предоставляет интерфейсы API независимым поставщикам программного обеспечения (ISV) для создания фильтров обработки пакетов. Например, для брандмауэров и антивирусного ПО.

Плохо написанный фильтр WFP может значительно снизить производительность сети сервера. дополнительные сведения см. в разделе перенос Packet-Processing драйверов и приложений в WFP в Windows Центр разработки.

Ссылки на все разделы данного руководства см. в разделе Настройка производительности сетевой подсистемы.

Источник