Est-ce que 'epoll' est la raison essentielle pour laquelle Tornadoweb (ou Nginx) est si rapide?

Question

Tornadoweb et Nginx sont des serveurs Web populaires pour le moment et de nombreux benchmarks montrent qu'ils ont une meilleure performance que Apache dans certaines circonstances. Donc ma question est:

Est-ce que 'epoll' est la raison la plus essentielle qui les rend si rapides? Et que puis-je apprendre de cela si je veux écrire un bon serveur socket?

Answer 1

Si vous cherchez à écrire un socket serveur, un bon point de départ est l'article C10K de Dan Kegel de quelques années:

http://www.kegel.com/c10k.html

J'ai aussi trouvé le Guide de Beej à la programmation du réseau pour être assez pratique:

http://beej.us/guide/bgnet/

Enfin, si vous avez besoin d'une grande référence, il y a UNIX Network Programming par W. Richard Stevens et. al .:

http://www.amazon.com/Unix-Network-Programming-Sockets-Networking/dp/0131411551/ref=dp_ob_title_bk

Quoi qu'il en soit, pour répondre à votre question, la principale différence entre Apache et Nginx est que Apache utilise un thread par client avec blocage d'E/S, alors que Nginx est mono-thread avec des non-blocage I/O. Le pool de travail d'Apache réduit la surcharge des processus de démarrage et de destorying, mais il fait toujours basculer le processeur entre plusieurs threads lorsqu'il sert plusieurs clients. Nginx, d'autre part, gère toutes les demandes dans un thread. Lorsqu'une requête doit effectuer une requête réseau (par exemple, vers un backend), Nginx attache un rappel à la requête backend et travaille ensuite sur une autre requête client active. En pratique, cela signifie qu'il retourne à la boucle d'événements (epoll, kqueue ou select) et demande des descripteurs de fichiers qui ont quelque chose à signaler. Notez que l'appel système dans la boucle d'événement principal est en fait une opération de blocage, car il n'y a rien à faire tant que l'un des descripteurs de fichier n'est pas prêt pour la lecture ou l'écriture. C'est la principale raison pour laquelle Nginx et Tornado sont efficaces pour servir de nombreux clients simultanés: il n'y a qu'un seul processus (économisant ainsi de la RAM) et un seul thread (économisant ainsi le CPU des changements de contexte). En ce qui concerne epoll, c'est juste une version plus efficace de select. S'il y a N descripteurs de fichiers ouverts (sockets), il vous permet de choisir ceux qui sont prêts pour la lecture en O (1) au lieu de O (N). En fait, Nginx peut utiliser select au lieu de epoll si vous le compilez avec l'option --with-select_module, et je parie que ce sera toujours plus efficace qu'Apache. Je ne suis pas aussi familier avec les internes Apache, mais un rapide grep montre qu'il utilise select et epoll - probablement lorsque le serveur écoute plusieurs ports/interfaces, ou s'il fait des requêtes backend simultanées pour un seul client. Incidemment, j'ai commencé avec ce genre de choses en essayant d'écrire un serveur socket de base et je voulais comprendre comment Nginx était si effrayant efficace. Après avoir parcouru le code source de Nginx et lu les guides/livres que j'ai liés à ci-dessus, j'ai découvert qu'il serait plus facile d'écrire des modules Nginx au lieu de mon propre serveur.Ainsi est né le maintenant semi-légendaire Guide de Emiller à Nginx Module de développement:

http://www.evanmiller.org/nginx-modules-guide.html

(Attention: le guide a été écrit contre Nginx 0,5-0,6 et les API peut avoir changé.) Si vous faites quoi que ce soit avec HTTP, je dirais que donner à Nginx un coup de feu parce qu'il a travaillé sur tous les détails poilus de traiter avec des clients stupides. Par exemple, le petit serveur socket que j'ai écrit pour le plaisir a bien fonctionné avec tous les clients - sauf Safari, et je n'ai jamais compris pourquoi. Même pour les autres protocoles, Nginx pourrait être la bonne solution; l'événement est assez bien résumé des protocoles, c'est pourquoi il peut aussi bien proxy HTTP que IMAP. La base de code de Nginx est extrêmement bien organisée et très bien écrite, avec une exception qui mérite d'être mentionnée. Je ne suivrais pas son exemple lorsqu'il s'agit de passer un analyseur de protocole à la main; Au lieu de cela, utilisez un générateur d'analyseur. J'ai écrit quelques trucs sur l'utilisation d'un générateur d'analyseur (Ragel) avec Nginx ici:

http://www.evanmiller.org/nginx-modules-guide-advanced.html#parsing

Tout cela était probablement plus d'informations que vous voulez, mais nous espérons que vous trouverez quelques-uns des utile.

Answer 2

Oui et non. Bien qu'ils utilisent tous les deux epoll, c'est techniquement qu'ils utilisent tous deux une boucle d'événements pour gérer les demandes. Vous pouvez trouver plus d'informations sur les boucles d'événements et leur utilisation au wikipedia.

Check out libevent (utilisé par gevent, généralement plus rapide & plus stable que la tornade) ou libev pour les implémentations.