Warum ist request_time viel größer als upstream_response_time in nginx access.log?

Question

Ich versuche, die Leistung einer Web-App zu verbessern. Bei der Profilerstellung der App habe ich festgestellt, dass die Antwortzeit akzeptabel ist (100ms-200ms), aber wenn ich ApacheBench zum Testen der App verwende, überschreitet die Reaktionszeit manchmal 1 Sekunde. Wenn ich genau auf den Protokollen sah, fand ich eine große Diskrepanz zwischen request_time und upstream_response_time gelegentlich:

"GET /wsq/p/12 HTTP/1.0" 200 114081 "-" "ApacheBench/2.3" 0.940 0.286 
"GET /wsq/p/31 HTTP/1.0" 200 114081 "-" "ApacheBench/2.3" 0.200 0.086 

Die upstream_response_time meiner Profilierung in dem Web-App ganz in der Nähe ist, aber request_time liegt in der Nähe zu einer Sekunde für die erste Anfrage .

Was könnte diese Diskrepanz verursachen?

Ich verstehe, request_time wird von dem ersten empfangenen Byte bis zum letzten Antwortbyte aufgezeichnet, es kann durch Netzwerkzustand und Client-Problem betroffen sein. Ich frage mich, was ich tun sollte, um den Durchschnitt request_time so viel wie möglich zu reduzieren?

Answer 1

Eine hohe request_time kann aufgrund eines Clients mit einer langsamen Verbindung sein, für die Sie nicht viel tun können. Ein hoher Wert von request_time bedeutet nicht unbedingt repräsentieren die Leistung Ihres Servers und/oder Anwendung.

Sie sollten wirklich nicht zu viel Zeit damit verbringen, auf request_time wenn Profilierung, sondern Dinge messen, wie die Reaktionszeit der Anwendung (dh. upstream_response_time).

Das heißt, es gibt einige Dinge, die Sie tun können, und kann beeinflussen die request_time. Einige von ihnen sind die folgenden:

Ihren Server auf einem Hochgeschwindigkeitsnetz
• Bewegen Sie den Server in der Nähe von dem Client
• die Nagle's algorithm
• Tune den TCP Server-Stack deaktivieren Verschieben
• (siehe this article). Dies wird jedoch nicht unbedingt einen großen Unterschied machen, da der Kernel sie für Sie optimiert.