httperfを使用したNginxストレステスト-Apacheサーバーとの大きなデータ転送の違い
HTML/PHPドキュメントを指すクアッドコアNginxサーバーで簡単なhttperfストレステストを実行しています。接続率が高いと、接続時間と応答時間がすぐに長くなります（以下の結果の接続時間の中央値と応答時間を参照してください）。これを困惑させるのは、同じコンテンツを提供するApacheWebサーバーでテストが繰り返される場合です。
Apacheサーバーは比較的汗をかきません。私が気付いた唯一の違いは、「ネットI/O」値にあります。これは、Nginxサーバーをテストしたときにはるかに大きくなります（3315.6KB /秒と55.5KB /秒）。応答時間も「転送」（849.6ミリ秒）から大きく寄与していますが、Apacheサーバーには「0.0」があります。私の最初の考えは、WebキャッシングがNginxサーバーで機能しておらず、より多くのデータが転送される原因であると考えていましたが、そうではなく、httperfはとにかくブラウザーではありません。
私のNginx構成は、理論的にはこのストレステストを問題なく処理できるはずです。データ転送量がパフォーマンス低下の原因だと思います。
だから私の質問は：Nginx構成は、同一のコンテンツをホストしているApacheサーバーと比較したデータ転送/コンテンツの長さのこの違いを説明できるでしょうか？
1000接続の単純な10秒テストの両方のサーバーでのhttperfの結果は次のとおりです。
NGINX
httperf --hog --server xxx.xxx.xxx.xxx --uri /test.html --num-conns 1000 --rate 100
httperf --hog --client=0/1 --server=xxx.xxx.xxx.xxx --port=80 --uri=/test.html --rate=100 --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
Maximum connect burst length: 1
Total: connections 1000 requests 1000 replies 1000 test-duration 11.776 s
Connection rate: 84.9 conn/s (11.8 ms/conn, <=214 concurrent connections)
Connection time [ms]: min 158.2 avg 1608.1 max 2695.7 median 1729.5 stddev 532.2
Connection time [ms]: connect 373.9
Connection length [replies/conn]: 1.000
Request rate: 84.9 req/s (11.8 ms/req)
Request size [B]: 84.0
Reply rate [replies/s]: min 69.2 avg 79.0 max 88.8 stddev 13.9 (2 samples)
Reply time [ms]: response 384.6 transfer 849.6
Reply size [B]: header 194.0 content 39702.0 footer 2.0 (total 39898.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0
CPU time [s]: user 0.18 system 11.57 (user 1.5% system 98.3% total 99.8%)
Net I/O: 3315.6 KB/s (27.2*10^6 bps)
Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
Apache
httperf --hog --server xxx.xxx.xxx.xxx --uri /test.html --num-conns 1000 --rate 100
httperf --hog --client=0/1 --server=xxx.xxx.xxx.xxx --port=80 --uri=test.html --rate=100 --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
Maximum connect burst length: 1
Total: connections 1000 requests 1000 replies 1000 test-duration 10.101 s
Connection rate: 99.0 conn/s (10.1 ms/conn, <=29 concurrent connections)
Connection time [ms]: min 53.0 avg 117.7 max 3074.8 median 72.5 stddev 264.3
Connection time [ms]: connect 79.7
Connection length [replies/conn]: 1.000
Request rate: 99.0 req/s (10.1 ms/req)
Request size [B]: 88.0
Reply rate [replies/s]: min 97.0 avg 99.2 max 101.4 stddev 3.1 (2 samples)
Reply time [ms]: response 38.1 transfer 0.0
Reply size [B]: header 231.0 content 255.0 footer 0.0 (total 486.0)
Reply status: 1xx=0 2xx=0 3xx=1000 4xx=0 5xx=0
CPU time [s]: user 1.23 system 8.86 (user 12.1% system 87.7% total 99.8%)
Net I/O: 55.5 KB/s (0.5*10^6 bps)
Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
応答の長さの違いは方法論的なものであることがわかります。 URLが書き直されていたため、このテスト中にApacheサーバーがすべての301コードを返していることに気づきませんでした。書き換えルールが適用するものと完全に一致するように、サーバーのURLとパスを変更する必要がありました。その後、コンテンツの長さは完全に一致し、Apacheサーバーは実際にこのテストでNginxよりも少し苦労しました。