本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 在 EC2 Windows 執行個體上最佳化網路效能
為了在您的 Windows 執行個體上達到使用增強型聯網的最大網路效能，您可能需要修改預設的作業系統組態。建議您針對需要高網路效能的應用程式進行下列組態變更。其他最佳化 (例如開啟檢查總和卸載與啟用 RSS) 已經在官方 Windows AMI 上配置。
**注意**
大多數使用案例都應該停用 TCP 煙囪卸載；此功能在 Windows Server 2016 中已被移除。
除了這些作業系統最佳化以外，您也應該考慮網路流量的最大傳輸單位 (MTU)，並根據您的工作負載和網路架構來調整。如需詳細資訊，請參閱[EC2 執行個體的網路最大傳輸單位 (MTU)](network_mtu.md)。
AWS 在 50us 叢集置放群組中啟動的執行個體與 99.9 百分位數的尾端延遲之間，定期測量平均往返延遲。如果您的應用程式需要始終很低的延遲，我們建議在 Nitro 系統中建構的固定效能執行個體上使用最新版本的 ENA 驅動程式。
## 設定接收端擴展 CPU 親和性
接收端調整 (RSS) 可用來將網路流量 CPU 負載分配至多個處理器。根據預設，Amazon 官方 Windows AMI 會設為啟用 RSS。ENA 彈性網路介面最多可提供八個 RSS 佇列。藉由為 RSS 佇列以及其他系統處理程序定義 CPU 親和性，您可以將 CPU 負載分配至多核心系統，以便處理更多網路流量。在 16 vCPU 以上的執行個體類型，我們建議使用 `Set-NetAdapterRSS` PowerShell cmdlet，藉以為所有彈性網路介面排除 RSS 組態的開機處理器 (超執行緒啟用時為邏輯處理器 0 和 1)，以免與各種系統元件競爭。
Windows 會察覺超執行緒，並確保單一網路介面卡 (NIC) 的 RSS 佇列總是置於不同的實體核心。因此，除非停用超執行緒，否則為了完全避免與 NIC 競爭，會將各 NIC 的 RSS 組態分配在 16 個邏輯處理器之間。`Set-NetAdapterRss` cmdlet 可讓您定義 BaseProcessorGroup、BaseProcessorNumber、MaxProcessingGroup、MaxProcessorNumber 和 NumaNode (選用) 的值，以定義有效邏輯處理器的各 NIC 範圍。如果無足夠的實體核心可以完全消除彈性網路介面間的競爭，視見面預期的工作負載而定，請盡量減少重疊範圍，或減少 ENI 範圍中的邏輯處理器數量 (換言之，少量管理網路介面可能不需要許多已指派的 RSS 佇列)。此外，如先前所述，各種元件必須在 CPU 0 上執行，因此當可使用足夠的 vCPU 時，我們建議從所有 RSS 組態中加以排除。
例如，當有 2 個 NUMA 節點並啟用超執行緒的 72 vCPU 執行個體出現三個彈性網路介面時，下列命令會將網路負載分配在兩顆 CPU 之間，而不會重疊並避免完全使用核心 0。
```
Set-NetAdapterRss -Name NIC1 -BaseProcessorGroup 0 -BaseProcessorNumber 2 -MaxProcessorNumber 16
Set-NetAdapterRss -Name NIC2 -BaseProcessorGroup 1 -BaseProcessorNumber 0 -MaxProcessorNumber 14
Set-NetAdapterRss -Name NIC3 -BaseProcessorGroup 1 -BaseProcessorNumber 16 -MaxProcessorNumber 30
```
注意，這些設定對於每個網路轉接器都是持續有效。如果有個執行個體調整大小成不同 vCPU 數的執行個體，您應針對每個已啟用彈性網路介面的執行個體重新評估 RSS 組態。此 cmdlet 的完整 Microsoft 文件可參閱：[Set-NetAdapterRss](https://learn.microsoft.com/en-us/powershell/module/netadapter/set-netadapterrss)。
SQL 工作負載的特別注意事項：我們還建議您檢查輸入/輸出執行緒親和性設定和彈性網路介面 RSS 組態，以盡量減少相同 CPU 的輸入/輸出和網路爭用。請參閱[伺服器組態：親和性遮罩](https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/affinity-mask-server-configuration-option)。