Node.js augmente-t-il réellement l'évolutivité?

J'ai lu sur le problème C10K, et particulièrement la partie qui se réfère aux E / S du serveur asynchrone. http://www.kegel.com/c10k.html#aio

Je pense que cela résume à peu près ce que Node.js fait sur le serveur, en permettant aux threads de traiter les demandes des utilisateurs tout en s'appuyant sur les interruptions d'E / S (événements) pour notifier les threads des travaux terminés, plutôt que de confier au thread la responsabilité de la travail CPU complet. Le thread peut continuer avec d'autres choses (non bloquant) et être averti quand un travail est terminé (par exemple, un fichier est trouvé ou une vidéo est compressée).

Cela signifie par la suite qu'un thread est plus «disponible» pour les sockets et donc pour les utilisateurs du serveur.

Ensuite, j'ai trouvé ceci: http://teddziuba.com/2011/10/straight-talk-on-event-loops.html

L'auteur affirme ici que bien que le framework événementiel (thread interrompu) puisse libérer des threads, il ne réduit pas réellement la quantité de travail qu'un CPU doit faire! La justification ici est que si, par exemple, un utilisateur demande à compresser une vidéo qu'il a téléchargée, le processeur doit toujours faire ce travail, et sera bloqué pendant qu'il le fait (par souci de simplicité, oublions le parallélisme ici - à moins que vous mieux connaître!).

Je suis un codeur simple, pas un administrateur de serveur ou quelque chose comme ça. Je suis simplement intéressé de savoir: Node.js est-il un cadeau des dieux du «cloud computing» ou est-ce de l'air chaud, et ne fera-t-il pas réellement gagner du temps et / ou de l'argent aux entreprises en améliorant l'évolutivité?

Merci beaucoup.

Bien sûr, tout travail lié au CPU va utiliser le CPU. Cela va bloquer le CPU dans le langage ou le framework dans lequel vous l'écrivez.

Node.js est idéal lorsque vous avez du travail lié aux E / S, pas au processeur. Je ne ferais pas de travail lourd dans Node, bien que cela puisse être fait. Node.js résout de vrais problèmes, pas ceux fictifs ou imaginaires comme les serveurs de nombres fibonacci . Ce n'est pas de «l'air chaud».

Bien que le document C10K soit quelque peu dépassé en ce qui concerne les détails de mise en œuvre, la concurrence basée sur les événements (le modèle de réacteur) est encore à certains égards supérieure à la planification préemptive. Par exemple, un modèle de planification préemptif peut planifier des threads alors qu'ils sont bloqués par E / S. Cela permet au nœud (et à d'autres outils comme Ruby's Event Machine et Python's Twisted) de mieux utiliser les cycles disponibles en passant plus de temps à faire du vrai travail et moins de blocage de temps.

Le multithreading améliore toujours les performances. L'explication originale est idiote car elle ne considère pas l'existence de plusieurs cœurs. Au moment où vous avez plus d'un noyau, les threads ne sont plus des threads. Ce sont des hyperthreads. Toute application gourmande en threads en bénéficiera plus qu'une seule application threadée.