Poignée long processus en cours d'exécution dans NodeJS?

J'ai vu quelques messages plus anciens touchant à ce sujet, mais je voulais savoir ce courant, l'approche moderne est.

Le cas d'utilisation est la suivante: (1) supposons que vous voulez faire une longue tâche en cours d'exécution sur un fichier vidéo, par exemple 60 secondes, dire jspm install qui peut prendre jusqu'à 60 secondes. (2) vous ne pouvez PAS diviser les tâches.

Autres exigences incluent:

  • besoin de savoir quand une tâche est terminée
  • agréable d'être en mesure d'arrêter une tâche en cours d'exécution
  • stabilité: si une tâche ne meurt pas, il ne veut pas arrêter le serveur
  • doit être capable de gérer les 100s de demandes simultanées

J'ai vu ces solutions mentionnées:

Moderne, la norme basée sur l'approche? Aussi, si nodejs n'est pas adapté pour ce type de tâche, alors que c'est aussi une réponse valable.

OriginalL'auteur U Avalos | 2015-10-06

  1. 10

    La réponse courte est: Dépend

    Si vous entendez un nodejs serveur, alors la réponse est non pour ce cas d'utilisation. Nodejs est le seul thread événement ne peut pas gérer le CPU des tâches, il est donc logique d'externaliser le travail à un autre processus ou thread. Toutefois, pour ce cas d'utilisation où le PROCESSEUR lié à l'exécution d'une tâche pendant une longue période, il est logique de trouver un moyen de la mise en attente des tâches... c'est à dire, il est logique d'utiliser une file d'attente de travail.

    Toutefois, pour ce cas d'utilisation particulier de l'exécution de code JS (jspm API), il est logique d'utiliser une file d'attente de travail qui utilise nodejs. Par conséquent, la solution est: (1) l'utilisation d'un serveur nodejs qui ne fait rien mais la file d'attente des tâches dans la file d'attente de travail. (2) l'utilisation d'un nodejs file d'attente de travail (comme kue) pour faire le travail. Utilisation cluster pour répartir le travail entre différents Processeurs. Le résultat est une simple unique serveur peut gérer des centaines de demandes (w/o d'étouffement). (Enfin, presque, voir la note ci-dessous...)

    Remarque:

    • la solution ci-dessus utilise processus. Je n'ai pas enquêter sur fil de solutions, car il semble que ceux-ci ont perdu la faveur du nœud.
    • la file d'attente de travail + cluster de vous donner l'équivalent d'un pool de threads.
    • oui, dans le pire des cas, le 100e parallèle demande prendra 25 minutes sur un 4-core de la machine. La solution est de faire tourner un autre travailleur de la file d'attente du serveur (si je ne me trompe pas, avec un db adossés à des travailleurs de la file d'attente comme kue c'est trivial---il suffit de faire de chaque serveur de point de point à la même db).

    OriginalL'auteur U Avalos

  2. 4

    Vous êtes de mentionner un CPU tâche, et depuis longtemps, ce n'est certainement pas un node.js chose. Vous avez également mentionné des centaines de tâches simultanément.

    Vous pouvez prendre un coup d'oeil à quelque chose comme Gearman job server pour des choses comme ça - c'est une solution dédiée.

    Sinon, vous pouvez toujours avoir Node.js gérer les demandes, tout simplement pas faire le travail d'exécution.

    Si c'est relativement acceptable d'avoir de plus bas puis une performance optimale, et vous voulez garder votre code en JavaScript, vous pouvez toujours le faire, mais vous devez avoir une sorte de file d'attente de travail - quelque chose comme Redis ou RabbitMQ vient à l'esprit.

    Je pense que la tâche de la file d'attente sera un must-have exigence de longue durée, des centaines/sec tâches, quel que soit votre exécution. Sauf si vous pouvez vous frayer ce travail sur d'autres serveurs/services/machines - alors vous n'avez pas de soins, votre Node.js l'API est juste une façade et de la couche de gestion pour le travail de cluster, puis Node.js est parfaitement ok pour le travail, et vous devez vous concentrer sur ce travail de cluster, et vous pouvez ensuite faire une meilleure question.

    Maintenant, node.js peut encore être utile pour vous, ici, il peut aider à gérer et à tenir ces centaines de tâches, en fonction d'où ils viennent (ie. vous pouvez autoriser uniquement les demandes passent par votre serveur de travail pour certains utilisateurs, ou de limiter la "pause" de la fonctionnalité d'autres etc.

    Avez-vous regardé neilk.net/blog/2013/04/30/... ?
    Ouais, c'est pas unduable. C'est juste souvent pas productif. Si une tâche prend une minute, et que vous exécutez 100 vidéos en parallèle sur un 4-core de la machine, cela signifie que votre dernière demande d'attendre 25 minutes pour la fin. Parfois, c'est ok, parfois il ne l'est pas. Lorsque la performance est pertinente, j'irais avec plus performants outils.

    OriginalL'auteur Zlatko