近くのサーバーから限られた数のIP（<4）から多数のhttpGETリクエストを受信します。タスクは、すべての要求に対して50ミリ秒未満の応答時間を維持することです。
tcp_tw_reuse1に設定してTCP接続の再利用を有効にip_local_port_rangeしました。1024〜65535に設定されています。
tcp_fin_timeout60（デフォルト）に設定されています。
Webサーバーのconfファイル（nginx）で、keepalive_timeoutを5に設定しました（これはtcpに関連していTIME_WAITますか？）。
現在、1秒間に5つのリクエストを受信しており、応答時間は約200ミリ秒です。
応答時間を大幅に改善するための支援が必要です（ローカル計算時間はごくわずかです）。
外に出て、これらは静的ファイルであり、cgiを通過していないと推測します。
私のプロファイリングとグーグルプロファイリングの経験から、ボトルネックを見つけること、または最も時間がかかる領域を最適化することがすべてであり、時間の5％を要するプロセスをスピードアップするためにすべての努力を費やすことはありません。
あなたのセットアップについてもっと知りたいのですが。1つのファイルの応答時間はどれくらいですか？pingの帰りのトリップ時間はどれくらいですか？ファイルの大きさはどれくらいですか？
たとえば、pingに150ミリ秒かかる場合、問題はネットワークであり、nginxconfではありません。ファイルがメガバイト単位の場合、nginxではありません。
応答時間が1秒あたり1〜30リクエストの間で異なる場合、より細かいnginxの調整よりも強力なものがあると思います。
状況にこれ以上光を当てることができますか？
--update--標準的なindex.phpページを取得するnginxサーバーでベンチマークを実行しました。
サーバー内からベンチマークした場合：
roderick@anon-webserver:~$ ab -r -n 1000 -c 100 http://anon.com/index.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking anon.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: nginx/0.8.54
Server Hostname: anon.com
Server Port: 80
Document Path: /index.php
Document Length: 185 bytes
Concurrency Level: 100
Time taken for tests: 0.923 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Total transferred: 380000 bytes
HTML transferred: 185000 bytes
Requests per second: 1083.19 [#/sec] (mean)
Time per request: 92.320 [ms] (mean)
Time per request: 0.923 [ms] (mean, across all concurrent requests)
Transfer rate: 401.96 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 4 1.6 4 9
Processing: 1 43 147.6 4 833
Waiting: 1 41 144.4 3 833
Total: 4 47 148.4 8 842
Percentage of the requests served within a certain time (ms)
50% 8
66% 8
75% 9
80% 9
90% 13
95% 443
98% 653
99% 654
100% 842 (longest request)
自宅のデスクトップからベンチマークした場合：
roderick@Rod-Dev:~$ ab -r -n 1000 -c 100 http://anon.com/index.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking anon.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: nginx/0.8.54
Server Hostname: anon.com
Server Port: 80
Document Path: /index.php
Document Length: 185 bytes
Concurrency Level: 100
Time taken for tests: 6.391 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Total transferred: 380000 bytes
HTML transferred: 185000 bytes
Requests per second: 156.48 [#/sec] (mean)
Time per request: 639.063 [ms] (mean)
Time per request: 6.391 [ms] (mean, across all concurrent requests)
Transfer rate: 58.07 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 40 260 606.9 137 3175
Processing: 81 214 221.7 140 3028
Waiting: 81 214 221.6 140 3028
Total: 120 474 688.5 277 6171
Percentage of the requests served within a certain time (ms)
50% 277
66% 308
75% 316
80% 322
90% 753
95% 867
98% 3327
99% 3729
100% 6171 (longest request)
私のOSはLinuxで、CPUは3年前のものです（500ドルのサーバーでした）。
私は設定ファイルに対して絶対的なことは何もしていません。
これは私に何を伝えますか？nginxは問題ではありません。
サーバーのネットワークが故障しているか、AWSがCPUを制限しています。私はおそらく両方を推測します。
修正がそれほど重要な場合は、専用サーバーを入手します。しかし、それは私の知識の範囲内でのみです。
nginxは、既存の接続を再利用する HTTP プロトコルの機能を制御keepalive_timeoutし、TCP TIME_WAIT状態とは関係ありません。(これは TCP キープアライブ プローブとも関係ありません。これらは約 2 時間のアイドル時間の後に送信されるため、ほとんどすべての場合に役に立ちません。)
HTTP1.1 クライアントとサーバー (および HTTP1.0 クライアントとサーバーのいくつかの組み合わせ) は、既存の接続を再利用して新しいデータを要求します。これにより、TCP 3 ウェイ ハンドシェイクに必要な時間が節約されます。クライアントとサーバーが使用できる場合は、このタイムアウト値を増やしてみてください。
TCP TIME_WAIT 状態は、切断された接続が切断されていることを両方のピアが認識していることを確認するために存在します。一方が再接続時にポートを再利用し、もう一方が FIN パケットを見逃した場合、新しい接続からのパケットが実際には古い接続用です。おっとっと。TIME_WAIT 状態はこれを防ぎます。通常、この数値をいじる必要はありません。毎秒 70 回接続しているクライアントを考えてみましょう。選択できるポートが 63k の場合、ポートの再利用の間隔は約 500 秒です。63k ポート / 70 cps == 1000 秒、ランダムな選択ではおそらくその半分になります。TIME_WAIT は 2 分近くあり、これは 7 ～ 8 分です。ピアから 1 秒あたり約 100 の接続を取得すると、TIME_WAIT についてもっと心配し始めます。
代わりに、あなたが遭遇したと思う問題はNagle のアルゴリズムであり、愚かな小さなパケットの山によってインターネットがオーバーランするのを防ぐために使用されます。Nagle のアルゴリズムでは、待機中にさらに多くのデータが到着することを期待して、少量のデータを送信するときに TCP システムを少し待機させます。これは、いったん問題が発生すると優れた機能ですが、接続を開始するときに許容できない遅延が発生する可能性があります。Nagle に対抗する通常のメカニズムは、TCP_NODELAYsocket オプションを設定することです。(まあ、アプリケーションのsend(2)およびrecv(2)呼び出しのパターンをいじる方が良いですが、常にオプションであるとは限りません。したがって、このバンドエイド.) 詳細についてtcp(7)は、setsockopt(2)マンページを参照してください。Nagle のアルゴリズムはTCP 遅延 ACK アルゴリズム、通常の ACK パケットのわずかな遅延ではなく、すぐにACK パケットを送信するように TCP に要求することもできます。これがTCP_QUICKACKソケット オプションです。
tcp(7)マンページには、必要なことを実行する可能性のある調整可能変数に関するヒントも記載されtcp_low_latencyています。オンにしてみてください。(この決定の結果はわかりませんが、私の推測では、ソケットごとのオプションではなく、サイト全体の Nagle と遅延 ACK に影響を与えるでしょう。)
クライアント ホストが非常に少ないため、TIME_WAIT 状態で閉じられた TCP 接続が、使用可能なポート番号を予約することによって遅くなる可能性があります。
多分あなたは試してみるべきです：
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
オプションに関する注意:
TIME_WAIT ソケットの高速リサイクルを有効にします。このオプションを有効にすると、NAT (ネットワーク アドレス変換) を使用するときに問題が発生するため、お勧めしません。