misurazione del tempo di richiesta http con node.js

Question

Uso node.js per inviare una richiesta http. Ho l'obbligo di misurare quanto tempo ci è voluto.

start = getTime() 
http.send(function(data) {end=getTime()}) 

Se chiamo getTime all'interno della richiamata risposta HTTP, v'è il rischio che il mio callback non viene chiamato immediatamente quando la risposta cames schiena a causa di altri eventi nella coda. Tale rischio esiste anche se uso questo codice sincrono java o C# sincrono per questo compito, poiché forse un altro thread ha attirato l'attenzione prima di me.

start = getTime() 
http.send() 
end=getTime() 

Come funziona node.js paragona ad altre piattaforme (sincrono) - ci fa il mio possibilità per una buona misura migliore o peggiore?

Answer 1

Grandi osservazioni!

Teoria:

Se si esegue micro-analisi comparativa, esiste una serie di considerazioni che possono potenzialmente falsare le misurazioni:

1. altri eventi nel ciclo di eventi che sono pronti a sparare lungo con l'invio HTTP in questione, e vengono eseguiti sequenzialmente prima che l'invio abbia una possibilità - nodo specifico.

2. Commutazione thread/processo che può verificarsi in qualsiasi momento all'interno dell'operazione di invio, generica.

3. I buffer di I/O del kernel in volumi limitati causano ritardi arbitrari - carico specifico del sistema operativo/del carico di lavoro/del sistema.

4. Latenza riscontrata nella raccolta del tempo di sistema - lingua/runtime specifico.

5. Chunking/Buffering dei dati: socket [implementazione http] specifico.

pratica:

Noe soffre (1), mentre un thread dedicato di Java/C# non hanno questo problema. Tuttavia, poiché il nodo implementa un modello di I/O non bloccante basato sugli eventi, altri eventi non causeranno effetti di blocco, ma verranno inseriti nella coda degli eventi. Saranno licenziati solo quelli pronti, e la latenza dovuta a loro dipenderà dalla quantità di lavoro I/O che devono eseguire e dalle azioni associate alla CPU eseguite nei rispettivi richiami associati. Questi, in pratica, diverrebbero trascurabili e uniformati nel confronto, a causa degli effetti più visibili dei punti da (2) a (5). Inoltre, le scritture sono generalmente non bloccanti, il che significa che verranno eseguite senza attendere che venga eseguita la successiva iterazione del ciclo. E infine, quando viene eseguita la scrittura, la richiamata viene emessa in linea e in sequenza, non c'è cedimento a un altro evento intermedio.

In breve, se si confronta un thread Java dedicato che esegue l'I/O di blocco con un codice Node, si vedranno le misure Java buone, ma in applicazioni su larga scala, lo sforzo di cambio del contesto del thread compenserà questo guadagno e il nodo le prestazioni si faranno notare.

Spero che questo aiuti.