Freigeben über

Leistungsoptimierung des Netzwerkadapters in Windows Server

In diesem Artikel wird beschrieben, wie Sie die Netzwerkadapterleistung in Windows Server-Umgebungen optimieren. Die Leistungsoptimierung des Netzwerkadapters kann den Durchsatz erheblich verbessern, die Latenz verringern und die Ressourcenauslastung für Ihre Server-Workloads maximieren.

Die richtige Abstimmung der Einstellungen für Ihre Netzwerkadapter hängt von den folgenden Variablen ab:

  • Dem Netzwerkadapter und seiner festgelegten Features
  • Der Typ der auf dem Server ausgeführten Workloads
  • Der Serverhardware- und Softwareressourcen
  • Von Ihren Leistungszielen in Bezug auf den Server

Die optimalen Optimierungseinstellungen hängen von Ihrer spezifischen Hardwarekonfiguration, Workloadanforderungen und Leistungszielen ab. Bewerten Sie vor der Implementierung von Änderungen die aktuelle Netzwerkleistung, und identifizieren Sie Verbesserungsbereiche. Einige Features und Einstellungen können je nach Version variieren.

In den folgenden Abschnitten werden einige Ihrer Feineinstellungsoptionen beschrieben.

Offload-Funktionen

Netzwerk-Offload-Funktionen übertragen Verarbeitungsprozesse von der CPU auf die Hardware des Netzwerkadapters, verringern die Systembelastung und verbessern die Netzwerkgesamtleistung. Zu den gängigen Offload-Funktionen gehören TCP-Prüfsummen-Offload, Large Send Offload (LSO) und Receive Side Scaling (RSS).

Das Aktivieren von Offloadfunktionen für Netzwerkadapter ist in der Regel von Vorteil. Möglicherweise ist der Netzwerkadapter jedoch nicht leistungsstark genug, um die Auslagerungsfunktionen mit hohem Durchsatz zu verarbeiten. Ziehen Sie beispielsweise einen Netzwerkadapter mit eingeschränkten Hardwareressourcen in Betracht. In diesem Fall kann das Aktivieren von Segmentierungsauslagerungsfeatures den maximal aufrechterhaltenen Durchsatz des Adapters verringern. Wenn der reduzierte Durchsatz jedoch akzeptabel ist, sollten Sie die Segmentierungsoffload-Features aktivieren.

Bei einigen Netzwerkadaptern ist es erforderlich, Auslagerungsfeatures unabhängig für Sende- und Empfängerpfade zu aktivieren.

Wichtig

Verwenden Sie die Offload-Features IPsec Task Offload oder TCP Chimney Offload nicht. Diese Technologien sind in Windows Server 2016 veraltet und können negative Auswirkungen auf die Server- und Netzwerkleistung haben. Darüber hinaus unterstützt Microsoft diese Technologien in Zukunft möglicherweise nicht.

Empfangsseitige Skalierung (RSS) für Webserver

RSS kann die Webskalierbarkeit und Leistung verbessern, wenn weniger Netzwerkadapter als logische Prozessoren auf dem Server vorhanden sind. Wenn der gesamte Webdatenverkehr die RSS-fähigen Netzwerkadapter durchläuft, können eingehende Webanforderungen von unterschiedlichen Verbindungen gleichzeitig über verschiedene CPUs hinweg verarbeitet werden.

Wichtig

Vermeiden Sie es, gleichzeitig RSS-fähige und Nicht-RSS-Netzwerkadapter auf demselben Server zu verwenden. Aufgrund der Lastenverteilungslogik in RSS und HTTP kann die Leistung erheblich sinken, wenn ein nicht RSS-fähiger Netzwerkadapter Webdatenverkehr auf einem Server akzeptiert, der über mindestens einen RSS-fähigen Netzwerkadapter verfügt. In diesem Fall sollten Sie RSS-fähige Netzwerkadapter verwenden oder RSS in den Netzwerkadaptereigenschaften auf der Registerkarte Erweiterte Eigenschaften deaktivieren.

Um zu bestimmen, ob ein Netzwerkadapter RSS-fähig ist, können Sie die RSS-Informationen in den Netzwerkadaptereigenschaften auf der Registerkarte Erweiterte Eigenschaften anzeigen.

RSS-Profile und RSS-Warteschlangen

Das standardmäßige vordefinierte RSS-Profil lautet NUMAStatic. Bevor Sie mit der Verwendung von RSS-Profilen beginnen, überprüfen Sie die verfügbaren Profile, um zu verstehen, wann sie von Vorteil sind und wie sie auf Ihre Netzwerkumgebung und Hardware angewendet werden.

Öffnen Sie z. B. den Task-Manager , und überprüfen Sie die logischen Prozessoren auf Ihrem Server. Wenn sie scheinbar nicht für den Empfang von Datenverkehr verwendet werden, können Sie versuchen, die Anzahl der RSS-Warteschlangen von der Standardeinstellung von zwei auf das Maximum zu erhöhen, das Ihr Netzwerkadapter unterstützt. Ihr Netzwerkadapter verfügt möglicherweise über Optionen zum Ändern der Anzahl der RSS-Warteschlangen als Bestandteil des Treibers.

Netzwerkadapterressourcen

Bei Netzwerkadaptern, die die manuelle Konfiguration von Ressourcen wie Puffern zum Empfangen und Senden gestatten, sollten Sie die zugeordneten Ressourcen erhöhen.

Einige Netzwerkadapter legen ihre Puffer zum Empfangen auf niedrige Werte fest, um vom Host zugeordneten Arbeitsspeicher zu sparen. Der geringe Wert hat verworfene Pakete und eine verringerte Leistung zur Folge. Daher sollten Sie in Szenarien, die „empfangsintensiv“ sind, die Anzahl des Pufferwerts für das Empfangen auf das Maximum festlegen.

Wenn ein Netzwerkadapter keine manuelle Ressourcenkonfiguration verfügbar macht, konfiguriert er die Ressourcen dynamisch, oder die Ressourcen werden auf einen festen Wert festgelegt, der nicht geändert werden kann.

Interruptüberprüfung

Zum Steuern der Interruptüberprüfung stellen einige Netzwerkadapter unterschiedliche Interruptüberprüfungsebenen oder Parameter zum Zusammenführen von Puffern (manchmal getrennt für Puffer zum Senden und Empfangen) zur Verfügung.

Sie sollten die Interruptüberprüfung für CPU-basierte Workloads in Betracht ziehen. Wenn Sie Interruptüberprüfung verwenden, sollten und einen Kompromiss zwischen CPU-Einsparungen und Latenz und erhöhten Host-CPU-Einsparungen in Betracht ziehen, da hier mehr Interrupts mit geringeren Latenzen vorliegen. Wenn der Netzwerkadapter keine Unterbrechungsmoderation durchführt, aber Pufferkoaleszenz verfügbar macht, können Sie die Leistung verbessern, indem Sie die Anzahl der koaleszierten Puffer erhöhen, um pro Sende- oder Empfangsvorgang mehr Puffer zu ermöglichen.

Paketverarbeitung mit geringer Latenz

Viele Netzwerkadapter bieten Optionen zum Optimieren der betriebssystembedingten Latenz. Latenz ist die Ablaufzeit, die zwischen der Netzwerktreiberverarbeitung eines eingehenden Pakets und dem Zurücksenden des Pakets durch den Netzwerktreiber vergeht. Diese Zeit wird für gewöhnlich in Mikrosekunden gemessen. Zum Vergleich wird die Übertragungszeit für Paketübertragungen über lange Distanzen hinweg normalerweise in Millisekunden (aufgrund der größeren Größe) gemessen. Diese Optimierung reduziert nicht die Zeit, die ein Paket auf dem Transportweg verbringt.

Die folgende Liste enthält einige Vorschläge zur Leistungsoptimierung für Mikrosekunden-empfindliche Netzwerke.

  • Wenn Ihr BIOS dies unterstützt, legen Sie das BIOS des Computers auf "Hohe Leistung" mit C-states deaktivierter Einstellung fest. Einige Systeme bieten eine höhere Leistung, wenn das Betriebssystem die Energieverwaltung steuert. Sie können Ihre Energieverwaltungseinstellungen über Die Energieeinstellungen oder mithilfe des powercfg Befehls überprüfen und anpassen. Weitere Informationen finden Sie unter Powercfg-Befehlszeilenoptionen.

  • Legen Sie das Energieverwaltungsprofil des Betriebssystems auf Höchstleistung fest. Diese Einstellung funktioniert nicht ordnungsgemäß, wenn das System-BIOS so eingestellt ist, dass die Steuerung des Betriebssystems für die Energieverwaltung deaktiviert wird.

  • Aktivieren Sie statische Auslagerungen. Aktivieren Sie beispielsweise die Einstellungen „UDP Checksums“, „TCP Checksums“ und „Send Large Offload (LSO)“.

  • Wenn der Datenverkehr mehrfach gestreamt wird, z. B. beim Empfangen von Multicastdatenverkehr mit hohem Volumen, aktivieren Sie RSS.

  • Deaktivieren Sie die Einstellung Interruptüberprüfung für Netzwerkkartentreiber, für die die geringstmögliche Latenz erforderlich ist. Denken Sie daran, dass diese Konfiguration mehr CPU-Zeit in Anspruch nehmen kann und einen Kompromiss darstellt.

  • Verarbeiten Sie Netzwerkadapterunterbrechungen und DPCs auf einem Kernprozessor, der CPU-Cache gemeinsam mit dem Kern verwendet, der durch das Programm verwendet wird (Benutzerthread), welches das Paket verarbeitet. Die CPU-Affinitätsoptimierung kann verwendet werden, um einen Prozess an bestimmte logische Prozessoren mit RSS-Konfiguration zu leiten. Das Verwenden des gleichen Kerns für den Interrupt, DPC und Benutzermodusthread zieht eine schlechte Leistung und eine erhöhte Last nach sich, da ISR, DPC und der Thread den Kern für sich beanspruchen.

Systemverwaltungsinterrupts

Viele Hardwaresysteme verwenden Systemverwaltungsunterbrechungen (System Management Interrupts, SMI) für verschiedene Wartungsfunktionen, z. B. Melden von Fehlerkorrekturcode (ECC)-Speicherfehlern, Beibehalten der Legacy-USB-Kompatibilität, Steuern des Lüfters und Verwalten von BIOS-gesteuerten Energieeinstellungen.

Der SMI ist der Interrupt mit der höchsten Priorität im System und versetzt die CPU in einen Verwaltungsmodus. In diesem Modus werden alle anderen Aktivitäten blockiert, während der SMI eine Interrupt Service Routine ausführt, die normalerweise im BIOS vorhanden ist. Dies kann leider Latenzspitzenwerte von 100 Mikrosekunden und mehr zur Folge haben.

Wenn Sie die geringe Latenz erzielen müssen, sollten Sie eine BIOS-Version Ihres Hardwareanbieters beziehen, die die SMIs auf den kleinsten möglichen Grad reduziert. Diese BIOS-Versionen werden häufig als Low-Latency-BIOS oder SMI-freies BIOS bezeichnet. In einigen Fällen ist es nicht möglich, dass eine Hardwareplattform SMI-Aktivitäten vollständig eliminiert, da sie verwendet wird, um wesentliche Funktionen wie Kühlventilatoren zu steuern.

Das Betriebssystem kann SMIs nicht steuern, da der logische Prozessor in einem speziellen Wartungsmodus ausgeführt wird, wodurch ein Eingriff des Betriebssystems verhindert wird.

Automatische Optimierung des TCP-Empfangsfensters

Der Windows-Netzwerkstapel verwendet ein Feature mit dem Namen TCP-Empfangsfenster-Autotuning-Ebene , um die TCP-Empfangsfenstergröße auszuhandeln. Dieses Feature kann eine definierte Empfangsfenstergröße für jede TCP-Kommunikation während des TCP Handshake aushandeln und die Leistung von TCP-Verbindungen verbessern.

Zuvor verwendete der Windows-Netzwerkstapel ein Empfangsfenster mit fester Größe von 65.535 Byte, das den gesamt potenziellen Durchsatz für Verbindungen beschränkte. Der insgesamt erreichbare Durchsatz von TCP-Verbindungen kann eventuell die Szenarien der Netzwerknutzung einschränken. Die automatische Einstellung des TCP-Empfangsfensters ermöglicht es diesen Szenarien, das Netzwerk vollständig zu verwenden.

Für ein TCP-Empfangsfenster mit einer bestimmten Größe können Sie die folgende Formel verwenden, um den Gesamtdurchsatz einer einzelnen Verbindung zu berechnen:

Gesamt erreichbare Durchsatzrate in Bytes = TCP Größe des Empfangsfensters in bytes * (1 / connection latency in seconds)

Bei einer 1Gbps-Verbindung mit einer Latenz von 10 ms beträgt der gesamt erreichbare Durchsatz beispielsweise nur 51 MBit/s. Dieser Wert ist für eine große Unternehmensnetzwerkinfrastruktur angemessen. Durch die automatische Anpassung des Empfangsfensters kann die Verbindung jedoch die volle Linienrate von 1 GBit/s erreichen.

Einige Anwendungen definieren die Größe des TCP-Empfangsfensters. Wenn die Anwendung die Größe des Empfangsfensters nicht definiert, bestimmt die Linkgeschwindigkeit die Größe wie folgt:

Verbindungsgeschwindigkeit Größe des Empfangsfensters
Weniger als 1 MBit/s 8 KB
1 MBit/s bis 100 MBit/s 17 KB
100 MBit/s bis 10 GBit/s 64 KB
10 GBit/s oder schneller 128 KB

Beispielsweise sollte auf einem Computer, auf dem ein Netzwerkadapter mit 1 Gbit/s installiert ist, die Fenstergröße 64 KB groß sein.

Dabei werden auch andere Features genutzt, um die Netzwerkleistung zu verbessern. Diese Features umfassen die restlichen TCP-Optionen, die in RFC 1323 definiert sind. Windows-basierte Computer können diese Features verwenden, um TCP-Empfangsfenstergrößen auszuhandeln, die kleiner sind, aber je nach Konfiguration auf einen definierten Wert skaliert werden. Dieses Verhalten erleichtert die Handhabung der Größen für Netzwerkgeräte.

Hinweis

Möglicherweise tritt ein Problem auf, bei dem das Netzwerkgerät nicht mit der TCP-Fensterskalaoption kompatibel ist, wie in RFC 1323 definiert und unterstützt daher nicht den Skalierungsfaktor. Wenden Sie sich in solchen Fällen an den Anbieter Ihres Netzwerkgeräts.

Ebenen der automatischen Optimierung

Sie können die automatische Einstellung des TCP-Empfangsfensters auf eine beliebige von fünf Ebenen festlegen. Die Standardebene lautet Normal. In der folgenden Tabelle werden die Ebenen beschrieben.

Grad Hexadezimalwert Kommentare
Normal (Standardeinstellung) 0x8 (Skalierungsfaktor 8) Das TCP-Empfangsfenster wird so festgelegt, dass es entsprechend nahezu allen Szenarien wächst.
Arbeitsunfähig Kein Skalierungsfaktor verfügbar Das TCP-Empfangsfenster wird auf den Standardwert festgelegt.
Eingeschränkt 0x4 (Skalierungsfaktor 4) Das TCP-Empfangsfenster wird so festgelegt, dass es über den Standardwert hinaus wächst, dieses Wachstum wird jedoch in einigen Szenarien eingeschränkt.
Stark eingeschränkt 0x2 (Skalierungsfaktor 2) Das TCP-Empfangsfenster wird so festgelegt, dass es über den Standardwert hinaus wächst, dies jedoch sehr konservativ.
Experimentell 0xE (Skalierungsfaktor 14) Das TCP-Empfangsfenster wird so festgelegt, dass es entsprechend extremen Szenarien wächst.

Wenn Sie eine Anwendung zum Erfassen von Netzwerkpaketen verwenden, sollte die Anwendung Daten melden, die den folgenden Beispielen für unterschiedliche Einstellungen der Fensterautotuning-Ebene ähneln.

Autotuning-Ebene: Normal (Standardzustand)

In diesem Beispiel wird die Ausgabe eines Paket-Analyzers gezeigt, wenn das TCP-Empfangsfenster-Autotuning auf Normal eingestellt ist. Der Skalierungsfaktor ist 8.

Frame: Number = 492, Captured Frame Length = 66, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
+ Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2667, Total IP Length = 52
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60975, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=4075590425, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240
SrcPort: 60975
DstPort: Microsoft-DS(445)
SequenceNumber: 4075590425 (0xF2EC9319)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 128 (0x80)
+ Flags: ......S. ---------------------------------------------------------> SYN Flag set
Window: 64240 ( Negotiating scale factor 0x8 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x8 Scale Factor.
Checksum: 0x8182, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 8 -----------------------------> Scale factor, defined by AutoTuningLevel
+ NoOption:
+ NoOption:
+ SACKPermitted:

AutoTuning-Ebene: Deaktiviert

In diesem Beispiel wird die Ausgabe eines Paketerfassungstools veranschaulicht, wenn die Autotuning-Stufe des TCP-Empfangsfensters auf Deaktiviert festgelegt ist. Der Skalierungsfaktor wird nicht verwendet.

Frame: Number = 353, Captured Frame Length = 62, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
+ Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2576, Total IP Length = 48
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60956, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=2315885330, Ack=0, Win=64240 ( ) = 64240
SrcPort: 60956
DstPort: Microsoft-DS(445)
SequenceNumber: 2315885330 (0x8A099B12)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 112 (0x70)
+ Flags: ......S. ---------------------------------------------------------> SYN Flag set
Window: 64240 ( ) = 64240 ----------------------------------------> TCP Receive Window set as 64K as per NIC Link bitrate. Note there is no Scale Factor defined. In this case, Scale factor is not being sent as a TCP Option, so it will not be used by Windows.
Checksum: 0x817E, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ NoOption:
+ SACKPermitted:

AutoTuning-Ebene: Eingeschränkt

Dieses Beispiel zeigt die Ausgabe eines Werkzeugs zur Paketerfassung, wenn die Stufe für die automatische Einstellung des TCP-Empfangsfensters auf Restricted. Der Skalierungsfaktor ist 4.

Frame: Number = 3, Captured Frame Length = 66, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
+ Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2319, Total IP Length = 52
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60890, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=1966088568, Ack=0, Win=64240 ( Negotiating scale factor 0x4 ) = 64240
SrcPort: 60890
DstPort: Microsoft-DS(445)
SequenceNumber: 1966088568 (0x75302178)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 128 (0x80)
+ Flags: ......S. ---------------------------------------------------------> SYN Flag set
Window: 64240 ( Negotiating scale factor 0x4 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x4 Scale Factor.
Checksum: 0x8182, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 4 -------------------------------> Scale factor, defined by AutoTuningLevel.
+ NoOption:
+ NoOption:
+ SACKPermitted:

Autotuning-Stufe: Streng eingeschränkt

Dieses Beispiel zeigt die Ausgabe eines Werkzeugs zur Paketerfassung, wenn die Stufe für die automatische Einstellung des TCP-Empfangsfensters auf Hochgradig Eingeschränkt. Der Skalierungsfaktor ist 2.

Frame: Number = 115, Captured Frame Length = 66, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
+ Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2388, Total IP Length = 52
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60903, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=1463725706, Ack=0, Win=64240 ( Negotiating scale factor 0x2 ) = 64240
SrcPort: 60903
DstPort: Microsoft-DS(445)
SequenceNumber: 1463725706 (0x573EAE8A)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 128 (0x80)
+ Flags: ......S. ---------------------------------------------------------> SYN Flag set
Window: 64240 ( Negotiating scale factor 0x2 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x2 Scale Factor.
Checksum: 0x8182, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 2 ------------------------------> Scale factor, defined by AutoTuningLevel
+ NoOption:
+ NoOption:
+ SACKPermitted:

Ebene der automatischen Optimierung: Experimentell

In diesem Beispiel wird die Ausgabe eines Paketerfassungstools angezeigt, wenn die Autotuning-Ebene des TCP-Empfangsfensters auf Experimental festgelegt ist. Der Skalierungsfaktor ist 14.

Frame: Number = 238, Captured Frame Length = 66, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
+ Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2490, Total IP Length = 52
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60933, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=2095111365, Ack=0, Win=64240 ( Negotiating scale factor 0xe ) = 64240
SrcPort: 60933
DstPort: Microsoft-DS(445)
SequenceNumber: 2095111365 (0x7CE0DCC5)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 128 (0x80)
+ Flags: ......S. ---------------------------------------------------------> SYN Flag set
Window: 64240 ( Negotiating scale factor 0xe ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0xe Scale Factor.
Checksum: 0x8182, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 14 -----------------------------> Scale factor, defined by AutoTuningLevel
+ NoOption:
+ NoOption:
+ SACKPermitted:

Überprüfen und Konfigurieren der Ebene der automatischen Optimierung für das TCP-Empfangsfenster

Sie können entweder Windows PowerShell-Cmdlets oder den netsh Windows-Befehl verwenden, um die Autotuning-Ebene des TCP-Empfangsfensters zu überprüfen oder zu ändern.

Hinweis

Ab Windows Server 2019 können Sie die Registrierung nicht mehr zum Konfigurieren der TCP-Empfangsfenstergröße verwenden. Weitere Informationen zu den veralteten Einstellungen finden Sie unter Veraltete TCP-Parameter.

Sie können das Get-NetTCPSetting Cmdlet verwenden, um die AutoTuning-Ebene zu überprüfen oder zu ändern. So überprüfen und ändern Sie die aktuelle Einstellung:

  1. Öffnen Sie PowerShell als Administrator, und führen Sie das folgende Cmdlet aus:

    Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal

    Die Ausgabe sieht in etwa wie das folgende Beispiel aus:

    SettingName          AutoTuningLevelLocal
-----------          --------------------
Automatic
InternetCustom       Normal
DatacenterCustom     Normal
Compat               Normal
Datacenter           Normal
Internet             Normal

  2. Führen Sie den folgenden Befehl aus, um die Einstellung zu ändern. Achten Sie darauf, dass Sie die gewünschte AutoTuning-Ebene festlegen <value> . Weitere Informationen finden Sie unter Set-NetTCPSetting.

    Set-NetTCPSetting -AutoTuningLevelLocal <value>

Windows-Filterplattform

Windows-Filterplattform (WFP), eingeführt in Windows Server 2008, stellt APIs für nicht von Microsoft unabhängige Softwareanbieter (ISVs) bereit, um Paketverarbeitungsfilter zu erstellen. WFP ermöglicht Es Drittanbietersoftware, Netzwerkdatenverkehr auf verschiedenen Ebenen des Netzwerkstapels zu prüfen, zu ändern oder zu filtern. Diese Funktionalität ist zwar für Sicherheitsanwendungen unerlässlich, kann jedoch Leistungsaufwand verursachen, wenn sie nicht ordnungsgemäß implementiert wird. Zu Beispielen zählen Firewall- und Antivirensoftware.

Ein schlecht geschriebener WFP-Filter kann die Netzwerkleistung eines Servers erheblich verringern. Weitere Informationen finden Sie unter Portieren von Paketverarbeitungstreibern und Apps zu WFP in Windows Dev Center.

Veraltete TCP-Parameter

Die folgenden Registrierungseinstellungen von Windows Server 2003 werden nicht mehr unterstützt und in späteren Versionen ignoriert.

  • TcpWindowSize
  • NumTcbTablePartitions
  • MaxHashTableSize

Alle diese Einstellungen befinden sich im folgenden Registrierungsunterschlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

  • Last updated on