Wie langsam sind TCP-Sockets im Vergleich zu Named Pipes unter Windows für localhost IPC?

Question

Ich entwickle einen TCP-Proxy, der vor einen TCP-Dienst gestellt wird, der zwischen 500 und 1000 aktive Verbindungen aus dem wilden Internet verarbeiten soll.

Der Proxy läuft auf demselben Computer wie der Dienst und ist größtenteils transparent. Der Dienst ist dem Proxy im Allgemeinen nicht bewusst, die einzige Ausnahme ist die Benachrichtigung der realen Remote-IP-Adresse der Clients.

Dies bedeutet, dass es für jeden eingehenden offenen TCP-Socket zwei weitere Sockets auf dem Server gibt: das zweite des Paars im Proxy und das auf dem echten Dienst hinter dem Proxy.

Die Größen send und recv für die beiden Proxy-Sockets sind auf 1024 Bytes eingestellt.

Was sind die Auswirkungen auf die Leistung? Wie langsam ist diese Konfiguration? Sollte ich mich bemühen, den Dienst zu ändern, um Named Pipes (oder einen anderen IPC-Mechanismus) zu verwenden, oder ist ein TCP-Socket von localhost zum größten Teil ein effizienter IPC?

Die Zusammenführung der beiden Apps ist keine Option. Im Moment sind wir bei den beiden Prozesskonfigurationen festgefahren.

EDIT: Der Grund für zwei separate Prozess auf der gleichen Hardware ist 100% Wirtschaftlichkeit. Wir haben nur einen Server, und wir haben nicht vor, mehr (kein Geld) zu bekommen.

Der TCP-Dienst ist eine ältere Software in Visual Basic 6, die unsere Erwartungen übertraf. Der Proxy ist C++. Wir haben nicht die Zeit, das Geld oder die Arbeitskraft, um den VB6-Code in eine moderne Programmierumgebung umzuschreiben und zu migrieren.

Der Proxy ist unser Versuch, ein bestimmtes Leistungsproblem auf dem Dienst zu beheben, eine DDoS attack, die wir von Zeit zu Zeit erhalten.

Der Proxy ist Open Source, and here is the project source code.

Answer 1

http://msdn.microsoft.com/en-us/library/aa178138(v=sql.80).aspx

Lassen Sie mich es für Sie zusammenzufassen. Wenn Sie sich Sorgen um die Leistung machen, verwenden Sie TCP/IP. Aber wenn Sie ein wirklich schnelles Netzwerk haben und sich keine Sorgen um die Leistung machen, dann wäre Named Pipes "ordentlich", weil es Ihnen möglicherweise etwas Code sparen könnte.

Ganz zu schweigen davon, wenn Sie bei TCP bleiben, dann haben Sie etwas, das skaliert werden kann, und sogar ausgeglichen, wenn die Zeit kommt.

Cheers,

Answer 2

Was ist der Grund, einen Proxy auf der gleichen Maschine zu haben, einfach nur neugierig?

Wie dem auch sei:

Es gibt mehrere Methoden für IPC, TCP/IP, Named Pipes sind vergleichbar in der Geschwindigkeit und Komplexität. Wenn Sie wirklich etwas haben wollen, das gut skaliert und fast keinen Overhead hat: Verwenden Sie Shared Memory. Am besten in Kombination mit einem Lock-Free-Algorithmus für die Weiterleitung der Zeiger (oder verwenden Sie einen Puffer für jeden Leser (der Proxy/der Dienst) und Writer (der Dienst/der Proxy)).

Answer 3

In dem beschriebenen Szenario ist es sehr unwahrscheinlich, dass die lokalen TCP-Verbindungen einen Engpass darstellen. Es bringt natürlich einige Overhead, aber das sollte vernachlässigbar sein, es sei denn, Ihre CPU ist bereits heiß.

Bei einer Schätzung, wenn die CPU-Auslastung Ihres Servers normalerweise unter 50% oder so (mit dem Proxy) liegt, ist es nicht wichtig, den mit den lokalen TCP-Verbindungen verbundenen Aufwand zu minimieren.

Wenn die CPU-Auslastung regelmäßig über 80% liegt, sollten Sie wahrscheinlich ein Profiling durchführen. Ich würde damit beginnen, die CPU-Auslastung zu vergleichen (oder, noch besser, die Leistung, wenn Sie es sinnvoll messen können), wenn der Proxy vorhanden ist, wenn nicht. Wenn der Proxy keine komplizierte Verarbeitung durchführt, ist der Overhead, der mit den zusätzlichen TCP-Verbindungen verbunden ist, wahrscheinlich ein beträchtlicher Teil des gesamten vom Proxy eingeführten Overheads, so dass Sie zumindest eine Schätzung Ihrer Größe erhalten sollten. d gewinnen mit einer effizienteren Form von IPC.

Answer 4

Es wird das gleiche sein (oder zumindest nicht messbar anders). Winsock ist schlau genug, um zu wissen, ob es mit einem Socket auf demselben Host kommuniziert, und in diesem Fall wird es so ziemlich alles unter der IP kurzschließen und Daten direkt von Puffer zu Puffer kopieren. In Bezug auf Named Pipes vs. Sockets, wenn Sie möglicherweise in Zukunft mit anderen Computern kommunizieren können, wählen Sie Sockets. Wenn Sie wissen, dass Sie das nie tun müssen, wählen Sie den, den Ihre Entwickler am vertrautesten oder am vertrautesten sind.

Answer 5

Für jeden, der kommt, um dies später zu lesen, möchte ich einige Ergebnisse hinzufügen, die die ursprüngliche Frage beantworten.

Für ein Dienstprogramm, das wir entwickeln, haben wir eine Netzwerkklasse, die Named Pipes oder TCP mit den gleichen Aufrufen verwenden kann. File-Transfer auf unserem Testsystem

Hier ist eine typische Schleife zurück:

TCP/IP-Transferzeit: 2,5 Sekunden
Named Pipes Transferzeit: 3,1 Sekunden

Nun, wenn Sie außerhalb der Maschine gehen und schließen Sie die Leistung für Named Pipes auf einen Remote-Computer in Ihrem Netzwerk ist viel schlimmer:

TCP/IP-Transferzeit: 12 Sekunden
Named Pipes Transferzeit: 2,5 Minuten (! Ja Minuten)

Ich realisiere, dass dies nur ein System ist (Windows 7) Aber ich denke, es ist ein guter Indikator dafür, wie langsam Named Pipes sein können ... und es scheint, als wäre TCP der Weg zu gehen.