Windows Netzwerk IOCP Skalierbarkeit über mehrere Kerne

Question

Das Verhalten ist das folgende: z. Ein Server-Worker mit 200 Sockets verarbeitet 100 K Echos pro Sekunde. Das Starten eines anderen Server-Worker auf demselben Port (mit der gleichen Anzahl von Sockets oder doppelt weniger für jeden Worker, spielt keine Rolle) verringert die Leistung des ersten Worker sofort auf etwa 50% und verbessert die Gesamtleistung pro Maschine (jeder Worker dient nur geringfügig) etwa 50K Echos pro Sekunde).

So ist Leistung der Maschine mit 6 Kernen ungefähr die selbe wie für Kernmaschine 1.

Ich habe verschiedene Ansätze mit z. Sie haben einen unabhängigen IOCP-Port für jeden Worker (indem Sie NumberOfConcurrentThreads in CreateIoCompletionPort auf 1 festlegen) oder versuchen einen gemeinsamen IOCP-Port für alle Worker (NumberOfConcurrentThreads ist gleich der Anzahl der Worker), die Leistung ist die gleiche. Meine Arbeiter teilen Null Daten, so dass es keine Sperren usw. gibt.

Ich hoffe, ich vermisse etwas und es ist nicht Windows Kernel Netzwerk Skalierbarkeit Probleme. Ich verwende Windows 7 Enterprise x64.

Natürlich war die Erwartung für eine annähernd lineare Skalierung der Leistung.

Kennt jemand die praktische Skalierbarkeit von IOCP über mehrere Kerne auf einer Maschine? Welche Situation ist zu erwarten, wenn die Anzahl aktiver Sockets steigt?

Vielen Dank!

Answer 1

Der übliche Ansatz für Nicht-NUMA-Systeme besteht darin, eine einzige IOCP für alle Verbindungen und eine Reihe von (in der Regel abstimmbaren) Threads zu haben, die die IOCP bedienen.

Sie können dann die Anzahl der Threads basierend auf der Anzahl der CPUs optimieren und feststellen, ob eine der von den Threads ausgeführten Aufgaben blockiert ist.

Die Leistung sollte sich gut skalieren, es sei denn, Sie verfügen über eine gemeinsam genutzte Ressource, auf die alle Verbindungen zugreifen müssen. Zu diesem Zeitpunkt wirkt sich der Konflikt für die freigegebene Ressource auf Ihre Skalierbarkeit aus.

Ich habe einige kostenlose IOCP-Code zur Verfügung here und eine einfache mehrere Client-Test, mit dem Sie Tausende von gleichzeitigen Verbindungen here ausführen können.

Bei NUMA-Systemen können die Dinge etwas komplexer sein, da idealerweise ein einzelner IOCP-, Thread-Pool- und Pufferzuordner pro NUMA-Knoten erforderlich ist, um Speicherzugriffe auf den lokalen Knoten zu behalten.