Un des gros inconvénients du modèle de Nodejs est d'avoir un seul fil d'exécution en collaboratif. Cela veut dire que si ce fil d'exécution est bloqué pendant 100ms pour calculer le hash d'un mot de passe avec une fonction moderne de hashage comme scrypt, il n'y a aucune autre requête HTTP qui va être traitée pendant ce temps et la latence va augmenter de 100ms pour toutes les requêtes de ce processus.
Effectivement c'est un traitement lourd qui doit être fait hors de l'event loop. Je ne connais pas Node, mais vertx permet ça sans problème (soit pour un appel simple et ponctuel un enrobage, soit pour un truc plus sophistiquer utiliser une forme de worker (avec le quel tu communique via un bus d'évènement qui passe par l'event loop)).
En tant que développeur, je peux créer plein de goroutines (des fils d'exécution très légers) et le runtime de Go les place dans des threads (en préemptif).
Le lien que tu m'a donné plus haut parle de stack de 2Kio (pour Go 1.5 ça a peut être évolué) soit si tu en lance un par connexion pour le C10K, si je ne me suis pas trompé dans mes comptes on est dans les 20Tio de mémoire consommée.
J'apprécie beaucoup d'avoir par défaut la version la plus efficace, alors que pour Nodejs, ça demande souvent encore un peu de boulot de passer d'un seul à plusieurs processus : écrire le petit bout de code pour cluster, faire attention aux variables globales qui ne le sont plus (cache, pools de connexions à la base de données), etc.
Il y a un gros mélange entre une implémentation (Node) et un modèle théorique (reactor), avec vertx c'est une ligne.
[^] # Re: Petit joueur
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 1.
Effectivement c'est un traitement lourd qui doit être fait hors de l'event loop. Je ne connais pas Node, mais vertx permet ça sans problème (soit pour un appel simple et ponctuel un enrobage, soit pour un truc plus sophistiquer utiliser une forme de worker (avec le quel tu communique via un bus d'évènement qui passe par l'event loop)).
Le lien que tu m'a donné plus haut parle de stack de 2Kio (pour Go 1.5 ça a peut être évolué) soit si tu en lance un par connexion pour le C10K, si je ne me suis pas trompé dans mes comptes on est dans les 20Tio de mémoire consommée.
Il y a un gros mélange entre une implémentation (Node) et un modèle théorique (reactor), avec vertx c'est une ligne.