nginx access.logのrequest_timeがupstream_response_timeよりもはるかに大きいのはなぜですか？
Webアプリのパフォーマンスを向上させようとしています。アプリ自体のプロファイリングでは、応答時間はかなり許容範囲内（100ms〜200ms）であることがわかりましたが、ApacheBenchを使用してアプリをテストすると、応答時間が1秒を超えることがあります。ログをよく見ると、request_timeとupstream_response_timeの間に大きな不一致があることがあります。
"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
upstream_response_timeはWebアプリでの私のプロファイリングに非常に近いですが、request_timeは最初のリクエストで1秒に近いです。
この不一致の原因は何ですか？
request_timeは、受信した最初のバイトから送信した最後の応答バイトまで記録されることを理解しています。ネットワークの状態やクライアントの問題の影響を受ける可能性があります。平均request_timeをできるだけ減らすにはどうすればよいですか？
request_timeが高いのは、接続が遅いクライアントが原因である可能性があり、そのために多くのことを行うことができません。したがって、高いrequest_timeは必ずしもサーバーやアプリケーションのパフォーマンスを表すとは限りません。
プロファイリングの際にrequest_timeに多くの時間を費やすべきではなく、代わりにアプリケーションの応答時間（つまり、upstream_response_time）。
そうは言っても、あなたができることがいくつかあり、mayはrequest_timeに影響を与えます。それらのいくつかは次のとおりです。
- サーバーを高速ネットワークに移動する
- サーバーをクライアントの近くに移動します
- Nagleのアルゴリズムを無効にする
- サーバーのTCPスタックを調整します（ この記事 を参照）。ただし、カーネルはあなたのためにそれらを調整します。