TNonblockingServer, TThreadedServer et TThreadPoolServer, lequel correspond le mieux à mon cas?

Question

Notre serveur analytique est écrit en C++. Il interroge essentiellement le moteur de stockage sous-jacent et renvoie une assez grande quantité de données structurées via l'épargne. Une demande typique prendra environ 0,05 à 0,6 secondes pour terminer dépend de la taille de la demande.

J'ai remarqué qu'il y a quelques options concernant le serveur Thrift que nous pouvons utiliser dans le code C++, en particulier TNonblockingServer, TThreadedServer et TThreadPoolServer. Il semble que TNonblockingServer soit la solution, car il peut supporter beaucoup plus de requêtes simultanées et utiliser encore un pool de threads derrière la scène pour croiser les tâches. Cela évite également le coût de construction/destruction des threads.

mise à jour de Facebook sur Thrift: http://www.facebook.com/note.php?note_id=16787213919

Chez Facebook, nous travaillons sur un client totalement asynchrone et le serveur C++. Ce serveur utilise des E/S pilotées par événements comme le TNonblockingServer actuel, mais son interface avec le code d'application est basée sur des rappels asynchrones. Cela nous permettra d'écrire des serveurs capables de traiter des milliers de requêtes simultanées (chacune nécessitant de faire des appels vers d'autres serveurs Thrift ou Memcache) avec seulement quelques threads.

Related posts sur stackover: Large number of simulteneous connections in thrift

Cela étant dit, vous serez pas nécessairement en mesure de réellement faire travailler plus vite (gestionnaires exécutons encore dans un pool de threads), mais plus les clients seront capable de se connecter à vous à la fois.

Je me demandais s'il y avait d'autres facteurs qui me manquent ici? Comment puis-je décider lequel correspond le mieux à mes besoins?

Answer 1

Les requêtes qui durent entre 50 et 600 millisecondes sont assez longues. Le temps qu'il faut pour créer ou détruire un thread est beaucoup moins que cela, alors ne laissez pas ce facteur dans votre décision en ce moment. Je choisirais celui qui est le plus facile à supporter et qui est le moins sujet aux erreurs. Vous voulez minimiser la probabilité de bogues de concurrence subtile. C'est pourquoi il est souvent plus facile d'écrire du code de gestion de transaction monothread qui bloque là où il le faut et dont bon nombre fonctionnent en parallèle, plutôt que d'avoir un modèle non bloquant plus complexe. Un thread bloqué peut ralentir une transaction individuelle, mais cela n'empêche pas le serveur d'effectuer d'autres tâches pendant qu'il attend.

Si la charge de transaction augmente (c'est-à-dire plus de transactions clients) ou si les demandes sont traitées plus rapidement (environ 1 milliseconde par transaction), le coût des transactions devient plus important. La métrique à surveiller est le débit: combien de transactions se terminent par unité de temps. La durée absolue d'une transaction unique est moins importante que le taux auquel elle est achevée, du moins si elle reste bien inférieure à une seconde.

Answer 2

Un gars sur Github a fait une belle comparaison

de TThreadedServer

de TThreadedServer génère un nouveau thread pour chaque connexion client, et chaque fil reste en vie jusqu'à ce que la connexion client est fermé.Cela signifie que s'il y a 1000 connexions client simultanées, TThreadedServer doit exécuter 1000 threads simultanément.

TNonblockingServer

TNonblockingServer a un fil dédié pour le réseau d'E/S. Le même thread peut également traiter des demandes, ou vous pouvez créer un pool séparé de threads de travail pour le traitement des demandes. Le serveur peut gérer de nombreuses connexions simultanées avec un petit nombre de threads car il n'a pas besoin de générer un nouveau thread pour chaque connexion.

TThreadPoolServer (non benchmarkée ici)

TThreadPoolServer est similaire à TThreadedServer; chaque connexion client obtient son propre thread de serveur dédié. Il est différent de TThreadedServer de 2 façons:

L'unité d'exécution du serveur revient au pool de threads après que le client a fermé la connexion pour la réutiliser. Le nombre de threads est limité. Le pool de threads ne dépassera pas la limite. Le client se bloque s'il n'y a plus de thread disponible dans le pool de threads. C'est beaucoup plus difficile à utiliser par rapport aux 2 autres serveurs.