Comment est Node.js intrinsèquement plus rapide quand il repose toujours sur les Threads en interne?

Il y a quelques différentes choses étant regroupés ici. Mais il commence avec le mème que les fils sont juste vraiment dur. Donc, si ils sont durs, vous êtes plus susceptible, lors de l'utilisation de threads pour 1) rupture en raison de bogues et 2) de ne pas les utiliser aussi efficacement que possible. (2) est celui que vous êtes en demandant au sujet.

Penser à l'un des exemples qu'il donne, lorsqu'une requête arrive et vous exécutez des requêtes, et de faire quelque chose avec les résultats de l'. Si vous écrivez dans une norme de procédure, le code pourrait ressembler à ceci:

result = query( "select smurfs from some_mushroom" );
//twiddle fingers
go_do_something_with_result( result );

Si la demande vient de vous a amené à créer un nouveau thread qui a couru le code ci-dessus, vous aurez un fil assis là, à ne rien faire du tout, tout, tout query() est en cours d'exécution. (Apache, selon Ryan, est à l'aide d'un seul fil pour satisfaire la demande d'origine alors que nginx est plus performant dans le cas dont il parle, car il n'est pas.)

Maintenant, si vous êtes vraiment intelligent, vous exprimer le code ci-dessus de façon à ce que l'environnement pourrait aller au large et faire autre chose pendant que vous exécutez la requête:

query( statement: "select smurfs from some_mushroom", callback: go_do_something_with_result() );

C'est essentiellement ce qu'node.js est en train de faire. Vous êtes essentiellement de décoration, d'une façon qui est pratique en raison de la langue et de l'environnement, donc les points sur les fermetures -- votre code de telle façon que l'environnement peut être intelligent sur ce qui fonctionne, et quand. De cette façon, node.js n'est-ce pas nouveau dans le sens qu'il a inventé asynchronous I/O (pas que quiconque prétendait quelque chose comme ça), mais c'est une nouveauté dans la façon dont elle est exprimée est un peu différent.

Note: quand je dis que l'environnement peut être intelligent sur ce qui fonctionne et quand, précisément ce que je veux dire, c'est que le thread qu'il utilise pour démarrer une I/O peut maintenant être utilisé pour traiter d'autres demande, ou de calcul, qui peut être fait en parallèle, ou de démarrer une autre parallèle I/O. (je ne suis pas certain nœud est suffisamment sophistiqué pour commencer plus de travail pour la même demande, mais vous voyez l'idée).

Je crains que je suis "de faire la mauvaise chose" ici, si nous supprimons donc moi et je m'en excuse. En particulier, je ne vois pas comment je crée le joli petit annotations que certaines personnes ont créé. Cependant, j'ai beaucoup de préoccupations et observations à faire sur ce fil.

1) Le commentaire de l'élément dans le pseudo-code dans l'un des populaires réponses

result = query( "select smurfs from some_mushroom" );
//twiddle fingers
go_do_something_with_result( result );

est essentiellement faux. Si le fil est de l'informatique, ce n'est pas se tourner les pouces, c'est de faire le travail nécessaire. Si, en revanche, c'est tout simplement d'attendre l'achèvement de IO, alors il est pas à l'aide de temps CPU, le point de l'ensemble de la thread de contrôle de l'infrastructure dans le noyau, c'est que le CPU va trouver quelque chose d'utile à faire. La seule façon de "se tourner les pouces" comme suggéré ici serait de créer une boucle d'interrogation, et la personne qui a codé un vrai serveur web est assez inepte pour le faire.

2) "Threads sont durs", n'a de sens que dans le contexte du partage des données. Si vous avez essentiellement des threads indépendants comme c'est le cas lors de la manipulation indépendante web demandes, puis le filetage est carrément simple, vous venez de code le flux linéaire de la façon de gérer un emploi, et de s'asseoir assez en sachant qu'il va traiter les requêtes multiples, et chacun d'eux sera effectivement indépendant. Personnellement, je crois que pour la plupart des programmeurs, l'apprentissage de la fermeture/mécanisme de rappel est plus complexe que de simplement le codage de haut en bas thread version. (Mais oui, si vous avez à communiquer entre les threads, la vie devient vraiment dur très rapide, mais je suis pas convaincu que la fermeture/mécanisme de rappel change vraiment que, il est juste limite vos options, parce que cette approche est encore possible de réaliser avec les threads. De toute façon, c'est une toute autre discussion, ce n'est vraiment pas pertinente ici).

3) jusqu'à présent, personne n'a présenté aucune preuve réelle pourquoi un type particulier de changement de contexte serait plus ou moins de temps que n'importe quel autre type. Mon expérience dans la création de multi-tâches noyaux (sur une petite échelle pour les contrôleurs embarqués, rien de fantaisie comme un "vrai" OS) suggère que ce ne serait pas le cas.

4) Toutes les illustrations que j'ai vu à ce jour qui visent à montrer comment beaucoup plus rapide Nœud est que les autres serveurs sont horriblement imparfait, cependant, ils sont défectueux dans un sens qui n'indirectement illustrer un avantage, je n'hésiterais pas accepter pour le Nœud (et c'est loin d'être négligeables). Le nœud n'a pas l'air comme il a besoin (ni même permis, en fait) de réglage. Si vous avez un modèle de thread, vous devez créer suffisamment de threads pour gérer la charge prévue. Ce faire de mal, et vous finirez avec la mauvaise performance. Si il y a trop peu de threads, puis le PROCESSEUR est inactif, mais pas en mesure d'accepter plus de demandes, de créer un trop grand nombre de threads, et vous perdrez de la mémoire du noyau, et dans le cas d'un environnement Java, vous aurez également être en train de perdre principal segment de mémoire. Maintenant, pour Java, de perdre du tas est le premier, le meilleur, moyen de vis de la performance du système, car efficace de collecte des ordures (actuellement, cela pourrait changer avec le G1, mais il semble que le jury est encore sur ce point, dès le début de 2013, au moins), il faut avoir beaucoup de pièces de rechange tas. Donc, il y a la question, le paramétrer avec trop peu de threads, vous avez Processeurs inactifs et les pauvres du débit, de la tune avec un trop grand nombre, et il échoue dans d'autres façons.

5) Il y a une autre façon dont j'accepte la logique de la revendication que le Nœud de l'approche "est plus rapide par concevoir", et qui est ce. La plupart des thread modèles à utiliser un temps d'tranches de changement de contexte modèle en couches sur le dessus de la plus appropriée (jugement de valeur d'alerte 🙂 et plus efficace (pas un jugement de valeur) préemptif modèle. Cela se produit pour deux raisons, tout d'abord, la plupart des programmeurs ne semblent pas comprendre la priorité de préemption, et, deuxièmement, si vous apprenez threading dans un environnement windows, le timeslicing est là que vous le vouliez ou pas (bien sûr, cela renforce le premier point; notamment, les premières versions de Java utilisée priorité de préemption sur Solaris implémentations, et timeslicing dans Windows. Parce que la plupart des programmeurs ne comprenais pas, et s'est plaint que "le filetage ne fonctionne pas dans Solaris" ils ont changé le modèle de timeslice partout). De toute façon, la ligne de fond est que timeslicing crée d'autres (et potentiellement inutiles) des changements de contexte. Chaque changement de contexte prend le temps CPU, et que le temps est effectivement retiré du travail qui peut être fait sur le vrai travail à la main. Cependant, la quantité de temps investi dans la commutation de contexte en raison de timeslicing ne devrait pas être plus qu'un très petit pourcentage de l'ensemble du temps, à moins que quelque chose de bizarre qui se passe, et il n'y a pas de raison que je vois de s'attendre à ce que ce soit le cas dans un simple serveur web). Donc, oui, l'excès de changements de contexte impliqués dans timeslicing sont inefficaces (et on ne peut pas se produire dans noyau threads comme une règle, d'ailleurs), mais la différence est de quelques pour-cent de débit, pas le genre de tout nombre de facteurs qui sont implicites dans les allégations de performances qui sont souvent implicites pour le Nœud.

De toute façon, des excuses pour que tous sont long et rambly, mais j'ai vraiment l'impression que jusqu'à présent, la discussion n'a pas prouvé quoi que ce soit, et je serais heureux d'entendre parler de quelqu'un dans une de ces situations:

a) une véritable explication de pourquoi le Nœud doit être le meilleur (au-delà de deux scénarios que j'ai décrit ci-dessus, le premier (mauvais réglage), je crois, l'explication réelle pour tous les tests que j'ai vu jusqu'à présent. ([edit], en fait, plus j'y pense, plus je me demandais si la mémoire utilisée par un grand nombre de piles peut être significatif ici. La valeur par défaut des tailles de tapis modernes pour les fils ont tendance à être assez énorme, mais la mémoire allouée par une fermeture événement basé sur le système serait seulement ce qui est nécessaire)

b) une véritable référence qui, de fait, donne une chance équitable à la partie filetée du serveur de son choix. Au moins de cette façon, je dois cesser de croire que les revendications sont essentiellement false ;> ([edit] c'est probablement plutôt plus fort que j'avais l'intention, mais je pense que les explications pour les avantages de performances sont incomplètes, au mieux, et les critères indiqués sont déraisonnables).

Cheers,
Toby

Fils sont utilisés seulement pour traiter avec les fonctions ayant pas asynchrone facilité, comme stat().

La stat() fonction est toujours de blocage, de sorte node.js besoin d'utiliser un thread pour effectuer l'appel, sans bloquer le thread principal (cas de la boucle). Potentiellement, pas de fil de la piscine ne sera jamais utilisé si vous n'avez pas besoin d'appeler ce genre de fonctions.