Pourquoi la méthode d'écriture dans l'objet http.ServerResponse dans node.js est-elle synchrone ?

Question

var http = require('http');
http.createServer(function(req,res){
    res.writeHeader(200, {'Content-Type' : 'text/html ; charset=utf-8'})
    if(req.url !== '/favicon.ico'){
        console.time('test');
        var c=1,a=2,b=3;        
        res.write(show()+''+c);
        c=a+b;
        res.write('<br />')
        res.write(c+'<br />');
        console.timeEnd('test');
        res.end()        
    }
}).listen(8000)
function show(){
    var str='';
    for(var i=0;i<10000;i++){
        str+=i*i*i*i+'<br />';
    }
    return str
}
console.log('server is running at http://127.0.0.1:8000')

Les deux dernières lignes sont 1 et 5 !
Le livre dit que l'objet http.ServerResponse implémente un stream.Writable (flux inscriptible). Cependant, les flux inscriptibles sont généralement asynchrones (tels que le flux fs write, le flux zlib, le stdin du sous-processus), ce qui est parfait pour le modèle de service piloté par événements. Maintenant, ce que j'ai testé est la synchronisation res.write, ce qui signifie que ce rappel doit être exécuté avant que le prochain rappel dans la file d'attente des événements puisse être exécuté ?
function(req,res) est le rappel de l'événement ruquest, ce qui signifie que si vous traitez des dizaines de milliers de requêtes simultanées, vous devrez exécuter des dizaines de milliers de function(req,res), même s'il n'y en a pas Applications gourmandes en CPU dans function(req,res) Un peu s'ajoute. Cela ne signifie-t-il pas qu'il y aura des retards dans l'accès des utilisateurs ? Mais le nœud est très doué pour gérer des IO intensives ? Ai-je mal pensé ?

J'ai créé cette fonction show intentionnellement, car js est monothread et n'est pas doué pour gérer les activités gourmandes en CPU, donc res.write(show()+''+c) prend plus de temps et est plus beau. ? Si Si res.write est asynchrone, alors c=a+b sera exécuté en premier alors c doit être 5 ;

 ;

Answer 1

L'avantage de node est qu'il peut gérer une concurrence élevée et gérer un grand nombre de requêtes, mais les opérations de gestion de réponse.write ou d'interrogation de la base de données sont gérées par un autre thread, tout comme un restaurant, avec un chef et un serveur ( Fil unique), contrairement au cadre général de service Web qui n'a qu'un seul chef et un serveur à temps partiel,
Donc votre situation ci-dessus n'est pas une IO intensive, mais comme, le chef du restaurant est trop occupé pour gérer vos plats, ce qui entraîne le serveur pour servir les plats lentement.

Answer 2

Évidemment, l'exécution show()时，还没有开始执行write(), donc votre méthode de test elle-même est fausse.

Answer 3

write Il écrit simplement les données dans le tampon interne puis les renvoie. Cela ne signifie pas qu'elles reviennent après l'envoi des données, donc cela ne prend presque pas de temps CPU

.