Port-Blockierung für mehrere Benutzeranfragen

Question

Ich habe eine Frage, mit der niemand zu helfen scheint. Wie wird dies in einem Produktionsmodus mit Tausenden von Anfragen gleichzeitig gehandhabt?

habe ich einen einfachen Testfall:

module.exports = { 
    index: function (req, res){ 
     if (req.param('foo') == 'bar'){ 
      async.series([ 
       function(callback){ 
        for (k=0; k <= 50000; k++){ 
         console.log('did something stupid a few times'); 
        } 

        callback(); 
       } 
      ], function(){ 
       return res.json(null); 
      }); 


     }else{ 
      return res.view('homepage', { 

      }); 
     } 

    } 
}; 

Nun, wenn ich zu http://localhost:1337/?foo=bar gehen wird es offensichtlich eine Weile warten, bevor er antwortet. Also, wenn ich jetzt eine andere Sitzung (andere Browser oder Inkognito, und gehen Sie zu http://localhost:1337/ Ich erwarte ein Ergebnis sofort. Stattdessen wartet es auf die andere Anfrage zu beenden und nur dann wird es diese Anfrage durchlaufen lassen.

Daher ist es nicht asynchron und es ist ein riesiges Problem, wenn ich so viel wie 2 Personen gleichzeitig die Bedienung dieser App. Ich meine, diese App wird Drop-Downs aus Datenbanken, HTML-Dateien usw. serviert

Meine Frage ist das: Wie geht man mit so einem Problem um? Ich höre das Wort "Versprechen vs Rückrufe" - ist das eine Art Lösung für dieses Problem?

Ich weiß über Clustering, aber das auf ly trennt die Anfragen über die Menge der CPUs, letztendlich werden Sie es beheben, indem Sie maximal 8 Personen gleichzeitig erlauben, ohne blockiert zu werden. Es hat gewonnen, t 100 Anfragen gleichzeitig zu behandeln ...

P.S. Dieser Test sollte das Beispiel vereinfachen, aber denke an jemanden, der eine Datei hochlädt, einen Webdienst, der zu einem anderen Server geht, ein Zahlungsterminal, das darauf wartet, dass ein Benutzer den Pin eingibt, jemanden, der eine Datei von der App herunterlädt usw ...

Answer 1

nodejs ist ereignisgesteuert und führt Ihr Javascript als single threaded aus. Solange also der Code von der ersten Anfrage in dieser for Schleife liegt, kann nodejs nichts anderes tun und wird nicht zum nächsten Event in der Event-Queue gelangen, also muss Ihre zweite Anfrage auf die erste warten beenden.

Nun, wenn Sie einen echten async Betrieb wie setTimeout() statt Ihrer großen for Schleife verwendet, dann könnte NodeJS andere Veranstaltungen Service, während die erste Anforderung für die setTimeout() wartete.

Die allgemeine Regel in Nodejs ist es, alles zu vermeiden, was eine Tonne CPU in Ihrer Haupt-Nodejs-App benötigt. Wenn Sie mit etwas CPU-intensivem System beschäftigt sind, sollten Sie entweder Cluster (so viele CPUs wie möglich) ausführen oder die CPU-intensive Arbeit in eine Arbeitswarteschlange verschieben, die von verschiedenen Prozessen bedient wird Zeitscheibe diese anderen Prozesse während der Haupt-Nodejs-Prozess bleibt frei und bereit, neue eingehende Anfragen zu bedienen.

Meine Frage ist dies: Wie behandelt man so ein Problem ??? Ich höre das Wort "Versprechen gegen Rückrufe" - ist das eine Art Lösung dafür?

Ich weiß über Clustering, aber das trennt nur die Anfragen über die Menge der CPUs, schließlich werden Sie es beheben, indem höchstens 8 Personen gleichzeitig ohne blockiert werden. Er gewann; t in der gleichen Zeit 100 Anfragen bearbeiten ...

Die meiste Zeit, ein Server-Prozess die meiste Zeit eines Ersuchens verbringt, Dinge zu tun, die in NodeJS asynchron sind (Lesen von Dateien auf andere reden Server, Datenbankoperationen usw.), wobei die eigentliche Arbeit außerhalb des nodejs-Prozesses erfolgt. Wenn dies der Fall ist, blockiert nodejs nicht und kann an anderen Anforderungen arbeiten, während die asynchronen Operationen von anderen Anforderungen ausgeführt werden.Das kleine bisschen CPU-Zeit, das diese Operationen koordiniert, kann durch Clustering weiter unterstützt werden, obwohl es sich wahrscheinlich lohnt, zuerst einen einzelnen Prozess zu testen, um zu sehen, ob Clustering wirklich benötigt wird.

P.S. Dieser Test sollte das Beispiel vereinfachen, aber denke an jemanden, der eine Datei hochlädt, einen Webdienst, der zu einem anderen Server geht, ein Zahlungsterminal, das darauf wartet, dass ein Benutzer den Pin eingibt, jemanden, der eine Datei von der App herunterlädt usw ...

Alle Operationen, die Sie hier erwähnt kann wirklich asynchron ausgeführt werden, damit sie nicht Ihre NodeJS App wie Ihre for Loopblock ist also im Grunde die for Schleife ist keine gute Simulation von irgendetwas davon. Sie müssen eine echte asynchrone Operation verwenden, um sie zu simulieren. Reale asynchrone Operationen erledigen ihre Arbeit außerhalb des Hauptknotens nodejs und posten dann einfach ein Ereignis in die Ereigniswarteschlange, wenn sie fertig sind, was es nodejs erlaubt, andere Dinge zu tun, während die asynchronen Operationen ihre Arbeit machen. Das ist der Schlüssel.