TNonblockingServer, TThreadedServer und TThreadPoolServer, welches passt am besten zu meinem Fall?

Question

Unser analytischer Server ist in C++ geschrieben. Es fragt im Grunde zugrunde liegenden Speicher-Engine und gibt eine ziemlich große strukturierte Daten über Sparsamkeit. Eine typische Anfrage dauert ungefähr 0,05 bis 0,6 Sekunden, um sie zu beenden, hängt von der Größe der Anfrage ab.

Ich habe festgestellt, dass es einige Optionen gibt, in Bezug darauf, welchen Thrift-Server wir im C++ - Code verwenden können, insbesondere TNonblockingServer, TThreadedServer und TThreadPoolServer. Es scheint, als ob TNonblockingServer der Weg ist, da es viel mehr gleichzeitige Anfragen unterstützen kann und immer noch einen Thread-Pool hinter der Szene verwendet, um die Aufgaben zu durchbrechen. Es vermeidet auch die Kosten des Konstruierens/Zerstörens der Fäden.

Facebook-Update auf Sparsamkeit: http://www.facebook.com/note.php?note_id=16787213919

Hier bei Facebook, wir arbeiten an einem voll asynchronen Client und Server für C++. Dieser Server verwendet ereignisgesteuerte E/A wie der aktuelle TNonblockingServer, aber seine Schnittstelle zu der Anwendungscode basiert auf asynchronen Rückrufen. Dies ermöglicht es uns, Server zu schreiben, die Tausende von gleichzeitigen Anfragen (die jeweils Aufrufe an andere Thrift oder Memcache Server erfordern) mit nur wenigen Threads bearbeiten können.

Related Posts über stackover: Large number of simulteneous connections in thrift

aber sagen, dass Sie nicht unbedingt in der Lage sein, tatsächlich schneller arbeiten (Handler noch in einem Thread-Pool ausgeführt werden), aber mehr Kunden werden Sie können sich sofort mit Ihnen verbinden.

Ich frage mich nur, gibt es noch andere Faktoren, die ich hier vermisse? Wie soll ich entscheiden, welches meinen Bedürfnissen am besten entspricht?

Answer 1

Anfragen, die 50-600 Millisekunden dauern, sind ziemlich lang. Die Zeit, die benötigt wird, um einen Thread zu erstellen oder zu zerstören, ist viel weniger als das, also lass diesen Faktor zu dieser Zeit nicht in deine Entscheidung einfließen. Ich würde diejenige auswählen, die am einfachsten zu unterstützen ist und die am wenigsten fehleranfällig ist. Sie möchten die Wahrscheinlichkeit von Nebenläufigkeitsfehlern minimieren.

Deshalb ist es oft einfacher, single-threaded transaction handling code zu schreiben, der blockiert, wo es benötigt wird, und viele davon parallel ausgeführt werden, als ein komplexeres nicht blockierendes Modell zu haben. Ein blockierter Thread kann eine einzelne Transaktion verlangsamen, verhindert jedoch nicht, dass der Server während des Wartens andere Aufgaben ausführt.

Wenn Ihre Transaktionslast zunimmt (d. H. Mehr Clienttransaktionen) oder die Anforderungen schneller verarbeitet werden (näherungsweise 1 Millisekunde pro Transaktion), wird der Transaktionsaufwand mehr zu einem Faktor. Die zu beachtende Metrik ist der Durchsatz: Wie viele Transaktionen werden pro Zeiteinheit abgeschlossen. Die absolute Dauer einer einzelnen Transaktion ist weniger wichtig als die Rate, mit der sie abgeschlossen werden, zumindest wenn sie deutlich unter einer Sekunde bleibt.

Answer 2

Ein Mann auf Github hat einen neuen Thread für jede Client-Verbindung

TThreadedServer laicht ein schöner Vergleich

TThreadedServer gemacht, und jeder Thread am Leben bleibt, bis der Client-Verbindung geschlossen ist.Das bedeutet, dass, wenn 1000 gleichzeitige Clientverbindungen vorhanden sind, TThreadedServer 1000 Threads gleichzeitig ausführen muss.

TNonblockingServer

TNonblockingServer hat ein Gewinde für Netzwerk gewidmet I/O. Derselbe Thread kann auch Anforderungen verarbeiten, oder Sie können einen separaten Pool von Worker-Threads für die Verarbeitung von Anforderungen erstellen. Der Server kann viele gleichzeitige Verbindungen mit einer kleinen Anzahl von Threads verarbeiten, da für jede Verbindung kein neuer Thread erstellt werden muss.

TThreadPoolServer (hier nicht gebenchmarkt)

TThreadPoolServer zu TThreadedServer ähnlich ist; Jede Clientverbindung erhält einen eigenen dedizierten Serverthread. Es unterscheidet sich von TThreadedServer auf zwei Arten:

Server-Thread geht zurück in den Thread-Pool, nachdem Client die Verbindung für die Wiederverwendung schließt. Die Anzahl der Threads ist begrenzt. Der Threadpool wird nicht über das Limit hinaus wachsen. Der Client hängt, wenn im Thread-Pool kein Thread mehr verfügbar ist. Es ist viel schwieriger zu verwenden als die anderen 2 Server.