Node.js sur les machines multicœurs

Node.js semble intéressant, MAIS je dois manquer quelque chose - Node.js n'est-il pas réglé uniquement pour fonctionner sur un seul processus et thread?

Alors, comment évolue-t-il pour les processeurs multicœurs et les serveurs multi-processeurs? Après tout, c'est génial de faire le plus rapidement possible un serveur monofil, mais pour des charges élevées, je voudrais utiliser plusieurs processeurs. Et il en va de même pour rendre les applications plus rapides - il semble aujourd'hui que la méthode consiste à utiliser plusieurs processeurs et à paralléliser les tâches.

Comment Node.js s'intègre-t-il dans cette image? Est-ce son idée de distribuer en quelque sorte plusieurs instances ou quoi?

[ Ce message est à jour en date du 2012-09-02 (plus récent que ci-dessus). ]

Node.js évolue absolument sur les machines multicœurs.

Oui, Node.js est un thread par processus. Il s'agit d'une décision de conception très délibérée et élimine la nécessité de gérer la sémantique de verrouillage. Si vous n'êtes pas d'accord avec cela, vous ne réalisez probablement pas encore à quel point il est incroyablement difficile de déboguer du code multithread. Pour une explication plus approfondie du modèle de processus Node.js et pourquoi il fonctionne de cette façon (et pourquoi il ne prendra JAMAIS en charge plusieurs threads), lisez mon autre article .

Alors, comment puis-je profiter de ma boîte à 16 cœurs?

Deux façons:

• Pour les tâches de calcul lourdes comme le codage d'image, Node.js peut lancer des processus enfants ou envoyer des messages à des processus de travail supplémentaires. Dans cette conception, vous auriez un thread gérant le flux d'événements et N processus effectuant des tâches de calcul lourdes et mâchant les 15 autres CPU.
• Pour faire évoluer le débit sur un service Web, vous devez exécuter plusieurs serveurs Node.js sur une seule boîte, un par cœur et répartir le trafic de demande entre eux. Cela offre une excellente affinité CPU et augmentera le débit de manière presque linéaire avec le nombre de cœurs.

Mise à l'échelle du débit sur un service Web

Depuis v6.0.X Node.js a inclus le module de cluster directement, ce qui facilite la configuration de plusieurs nœuds de travail pouvant écouter sur un seul port. Notez que ce n'est PAS le même que l'ancien module "cluster" learnboost disponible via npm .

if (cluster.isMaster) {
  // Fork workers.
  for (var i = 0; i < numCPUs; i++) {
    cluster.fork();
  }
} else {
  http.Server(function(req, res) { ... }).listen(8000);
}

Les travailleurs seront en concurrence pour accepter de nouvelles connexions, et le processus le moins chargé est le plus susceptible de gagner. Cela fonctionne assez bien et peut augmenter le débit assez bien sur une boîte multicœur.

Si vous avez suffisamment de charge pour vous soucier de plusieurs cœurs, vous voudrez également faire quelques choses:

1. Exécutez votre service Node.js derrière un proxy Web comme Nginx ou Apache - quelque chose qui peut limiter la connexion (sauf si vous voulez que les conditions de surcharge réduisent complètement la boîte), réécrire les URL, servir du contenu statique et proxy d'autres sous-services.

2. Recyclez régulièrement vos processus de travail. Pour un processus de longue durée, même une petite fuite de mémoire finira par s'additionner.

3. Configuration de la collecte / surveillance des journaux

PS: Il y a une discussion entre Aaron et Christopher dans les commentaires d'un autre article (à ce jour, c'est le premier article). Quelques commentaires à ce sujet:

• Un modèle de socket partagé est très pratique pour permettre à plusieurs processus d'écouter sur un seul port et de concurrencer pour accepter de nouvelles connexions. Sur le plan conceptuel, vous pourriez penser à Apache préfork faisant cela avec la mise en garde importante que chaque processus n'acceptera qu'une seule connexion, puis mourra. La perte d'efficacité pour Apache est dans la surcharge de forking de nouveaux processus et n'a rien à voir avec les opérations de socket.
• Pour Node.js, avoir N travailleurs en concurrence sur un seul socket est une solution extrêmement raisonnable. L'alternative consiste à configurer un frontal sur boîte comme Nginx et à disposer de ce trafic proxy vers les différents travailleurs, en alternant entre les travailleurs pour attribuer de nouvelles connexions. Les deux solutions ont des caractéristiques de performances très similaires. Et comme, comme je l'ai mentionné ci-dessus, vous voudrez probablement que Nginx (ou une alternative) gère votre service de nœud de toute façon, le choix ici est vraiment entre:

Ports partagés: nginx (port 80) --> Node_workers x N (sharing port 3000 w/ Cluster)

contre

Ports individuels: nginx (port 80) --> {Node_worker (port 3000), Node_worker (port 3001), Node_worker (port 3002), Node_worker (port 3003) ...}

Il y a sans doute certains avantages à la configuration des ports individuels (potentiel d'avoir moins de couplage entre les processus, d'avoir des décisions d'équilibrage de charge plus sophistiquées, etc.), mais c'est certainement plus de travail à configurer et le module de cluster intégré est un faible -alternative de complexité qui fonctionne pour la plupart des gens.

Une méthode consisterait à exécuter plusieurs instances de node.js sur le serveur, puis à placer un équilibreur de charge (de préférence un non bloquant comme nginx) devant eux.

Ryan Dahl répond à cette question dans le discours technique qu'il a donné à Google l'été dernier. Pour paraphraser, "exécutez simplement plusieurs processus de nœuds et utilisez quelque chose de sensé pour leur permettre de communiquer. Par exemple IPC de style sendmsg () ou RPC traditionnel".

Si vous voulez vous salir les mains immédiatement, consultez le module spark2 Forever . Il facilite la génération de plusieurs processus de nœuds. Il gère la configuration du partage de port, afin qu'ils puissent chacun accepter des connexions au même port, ainsi que la réapparition automatique si vous voulez vous assurer qu'un processus est redémarré si / quand il meurt.

MISE À JOUR - 11/11/11 : Le consensus dans la communauté des nœuds semble être que le cluster est maintenant le module préféré pour gérer plusieurs instances de nœuds par machine. Forever vaut également le détour.

Vous pouvez utiliser le module de cluster . Vérifiez ça .

var cluster = require('cluster');
var http = require('http');
var numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
    // Fork workers.
    for (var i = 0; i < numCPUs; i++) {
        cluster.fork();
    }

    cluster.on('exit', function(worker, code, signal) {
        console.log('worker ' + worker.process.pid + ' died');
    });
} else {
    // Workers can share any TCP connection
    // In this case its a HTTP server
    http.createServer(function(req, res) {
        res.writeHead(200);
        res.end("hello world\n");
    }).listen(8000);
}

Plusieurs nœuds exploitent tous les cœurs que vous pouvez avoir.
Jetez un œil à http://github.com/kriszyp/multi-node .

Pour des besoins plus simples, vous pouvez démarrer plusieurs copies de nœud sur différents numéros de port et placer un équilibreur de charge devant eux.

Node Js prend en charge le clustering pour tirer pleinement parti de votre processeur. Si vous ne l'exécutez pas avec le cluster, vous perdez probablement vos capacités matérielles.

Le clustering dans Node.js vous permet de créer des processus distincts qui peuvent partager le même port de serveur. Par exemple, si nous exécutons un serveur HTTP sur le port 3000, il s'agit d'un serveur fonctionnant sur un seul thread sur un seul cœur de processeur.

Le code ci-dessous vous permet de regrouper votre application. Ce code est le code officiel représenté par Node.js.

var cluster = require('cluster');
var numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
    // Fork workers.
    for (var i = 0; i < numCPUs; i++) {
        cluster.fork();
    }

    Object.keys(cluster.workers).forEach(function(id) {
        console.log("I am running with ID : " + cluster.workers[id].process.pid);
    });

    cluster.on('exit', function(worker, code, signal) {
        console.log('worker ' + worker.process.pid + ' died');
    });
} else {

    //Do further processing.
}

consultez cet article pour le tutoriel complet

Comme mentionné ci-dessus, Cluster dimensionnera et équilibrera la charge de votre application sur tous les cœurs.

ajouter quelque chose comme

cluster.on('exit', function () {
  cluster.fork();
});

Redémarrera tous les travailleurs défaillants.

De nos jours, beaucoup de gens préfèrent également PM2 , qui gère le clustering pour vous et fournit également des fonctionnalités de surveillance intéressantes .

Ensuite, ajoutez Nginx ou HAProxy devant plusieurs machines fonctionnant avec le clustering et vous avez plusieurs niveaux de basculement et une capacité de charge beaucoup plus élevée.

La future version du nœud vous permettra de bifurquer un processus et de lui passer des messages et Ryan a déclaré qu'il voulait trouver un moyen de partager également les gestionnaires de fichiers, donc ce ne sera pas une implémentation Web Worker simple.

Pour le moment, il n'y a pas de solution facile pour cela, mais c'est encore très tôt et le nœud est l'un des projets open source les plus rapides que j'ai jamais vus, alors attendez-vous à quelque chose de génial dans un avenir proche.

Spark2 est basé sur Spark qui n'est désormais plus maintenu. Cluster est son successeur, et il a des fonctionnalités intéressantes, comme la génération d'un processus de travail par cœur de processeur et la réapparition de travailleurs morts.

J'utilise Node Worker pour exécuter des processus de manière simple à partir de mon processus principal. Semble fonctionner très bien pendant que nous attendons la manière officielle de contourner.

Le nouveau sur le bloc ici est "Up" de LearnBoost .

Il fournit des «rechargements sans temps d'arrêt» et crée en outre plusieurs travailleurs (par défaut, le nombre de CPU, mais il est configurable) pour fournir le meilleur de tous les mondes.

Il est nouveau, mais semble assez stable, et je l'utilise avec bonheur dans l'un de mes projets en cours.

Le module de cluster vous permet d'utiliser tous les cœurs de votre machine. En fait, vous pouvez en profiter en seulement 2 commandes et sans toucher à votre code en utilisant un gestionnaire de processus très populaire pm2 .

npm i -g pm2
pm2 start app.js -i max

Vous pouvez exécuter votre application node.js sur plusieurs cœurs en utilisant le module de cluster en combinaison avec le module os qui peut être utilisé pour détecter le nombre de CPU dont vous disposez.

Par exemple, imaginons que vous avez un servermodule qui exécute un serveur http simple sur le backend et que vous souhaitez l'exécuter pour plusieurs processeurs:

// Dependencies.
const server = require('./lib/server'); // This is our custom server module.
const cluster = require('cluster');
const os = require('os');

 // If we're on the master thread start the forks.
if (cluster.isMaster) {
  // Fork the process.
  for (let i = 0; i < os.cpus().length; i++) {
    cluster.fork();
  }
} else {
  // If we're not on the master thread start the server.
  server.init();
}

Il est également possible de concevoir le service Web comme plusieurs serveurs autonomes qui écoutent les sockets Unix, de sorte que vous pouvez pousser des fonctions telles que le traitement des données dans des processus séparés.

Ceci est similaire à la plupart des architectures de serveur Web scrpting / base de données où un processus cgi gère la logique métier, puis pousse et extrait les données via un socket Unix vers une base de données.

la différence étant que le traitement des données est écrit comme un serveur web de noeud écoutant sur un port.

c'est plus complexe, mais en fin de compte, c'est là où le développement multicœur doit aller. une architecture multiprocessus utilisant plusieurs composants pour chaque requête Web.

Il est possible de faire évoluer NodeJS sur plusieurs boîtiers à l'aide d'un équilibreur de charge TCP pur (HAProxy) devant plusieurs boîtiers exécutant chacun un processus NodeJS.

Si vous avez alors des connaissances communes à partager entre toutes les instances, vous pouvez utiliser un magasin Redis central ou similaire auquel vous pouvez ensuite accéder à partir de toutes les instances de processus (par exemple à partir de toutes les boîtes)