Pourquoi les applications réseau basées sur des événements sont-elles intrinsèquement plus rapides que les applications à thread?

Question

Nous avons tous lu les tests de performance et connaissons les faits: les serveurs de réseau asynchrones basés sur des événements sont plus rapides que leurs homologues threadés. Pensez lighttpd ou Zeus contre Apache ou IIS. Pourquoi est-ce?

Answer 1

Je pense que la question des événements par rapport aux threads n’est pas la question; c’est une entrée / sortie multiplexée non bloquante, des sockets sélectionnables, une solution vs un pool de threads.

Dans le premier cas, vous gérez toutes les entrées qui arrivent indépendamment de leur utilisation. Il n'y a donc pas de blocage sur les lectures - un seul "écouteur". L'unique thread d'écoute transmet les données à ce que peuvent être des threads de travail de différents types, plutôt qu'à un pour chaque connexion. Encore une fois, aucun blocage lors de l'écriture des données, le gestionnaire de données peut simplement l'exécuter séparément. Parce que cette solution consiste principalement en lecture / écriture IO, elle n'occupe pas beaucoup de temps CPU. Votre application peut donc en faire ce qu'elle veut.

Dans une solution de pool de threads, vous avez des threads individuels gérant chaque connexion. Ils doivent donc partager le temps nécessaire pour activer et désactiver le contexte, chacun "écoutant". Dans cette solution, le processeur et les opérations d'E / S se trouvent dans le même fil, ce qui correspond à une tranche de temps. Vous devez donc attendre que les opérations d'E / S se terminent par thread (blocage), ce qui est généralement réalisable sans utiliser le temps de calcul.

Google pour les E / S non bloquantes pour plus de détails - et vous pouvez également trouver des comparaisons par rapport aux pools de threads.

(si quelqu'un peut clarifier ces points, n'hésitez pas)

Answer 2

Les applications pilotées par les événements ne sont pas intrinsèquement plus rapides.

De Pourquoi les événements sont-ils une mauvaise idée (pour les serveurs à haute concurrence) :

We examine the claimed strengths of events over threads and show that the
weaknesses of threads are artifacts of specific threading implementations
and not inherent to the threading paradigm. As evidence, we present a
user-level thread package that scales to 100,000 threads and achieves
excellent performance in a web server.

C’était en 2003. Il est évident que l’état du threading sur les systèmes d’exploitation modernes s’est amélioré depuis.

Écrire le coeur d’un serveur événementiel signifie réinventer le multitâche coopératif (style Windows 3.1) dans votre code, très probablement sur un système d’exploitation prenant déjà en charge le multitâche préventif approprié, sans bénéficier d’une commutation transparente du contexte. Cela signifie que vous devez gérer sur le tas l'état qui serait normalement impliqué par le pointeur d'instruction ou stocké dans une variable de pile. (Si votre langue les utilise, les fermetures soulagent considérablement cette douleur. Essayer de le faire en C est beaucoup moins amusant.)

Cela signifie également que vous gagnez tous les avertissements qu'implique le multitâche coopératif. Si l'un de vos gestionnaires d'événements prend un certain temps à s'exécuter pour une raison quelconque, il bloque ce fil d'événements. Les demandes totalement indépendantes sont en retard. Même de longues opérations invasives sur le processeur doivent être envoyées ailleurs pour éviter cela. Lorsque vous parlez du cœur d'un serveur à haute concurrence, «opération longue» est un terme relatif, de l'ordre de la microseconde, pour un serveur censé gérer 100 000 demandes par seconde. J'espère que le système de mémoire virtuelle ne doit jamais extraire les pages du disque pour vous!

Il peut être difficile d’obtenir de bonnes performances avec une architecture basée sur les événements, en particulier si vous prenez en compte la latence et pas uniquement le débit. (Bien sûr, vous pouvez également commettre de nombreuses erreurs avec les threads. La concurrence est toujours difficile.)

Quelques questions importantes pour l'auteur d'une nouvelle application serveur:

• Quelles sont les performances des threads sur les plates-formes que vous avez l'intention de prendre en charge aujourd'hui? Vont-ils être votre goulot d'étranglement?
• Si vous êtes toujours bloqué par une mauvaise implémentation de thread: pourquoi personne ne le résout-il?

Answer 3

Cela dépend vraiment de ce que vous faites. la programmation événementielle est certainement délicate pour des applications non triviales. Être un serveur Web est vraiment un problème trivial et bien compris, et les modèles à commande événementielle ou à thread fonctionnent assez bien avec les systèmes d’exploitation modernes.

Développer correctement des applications serveur plus complexes dans un modèle d’événement est généralement assez délicat - les applications à threads sont beaucoup plus faciles à écrire. Cela peut être le facteur décisif plutôt que la performance.

Answer 4

Cela ne concerne pas vraiment les discussions. Cela concerne la façon dont les threads sont utilisés pour répondre aux demandes. Pour quelque chose comme lighttpd, vous avez un seul thread qui dessert plusieurs connexions via des événements. Pour les versions plus anciennes d’apache, vous aviez un processus par connexion et le processus s’éveillait sur les données entrantes, de sorte que vous obteniez un très grand nombre de demandes lorsque celles-ci étaient nombreuses. Maintenant, avec MPM, apache est également basé sur les événements, voir événement apache MPM . .