我在四核Nginx服务器上运行一个简单的httperf压力testing，指向一个HTML / PHP文档。 大的连接速度很快开始出现高连接和响应时间（请参阅下面结果中的中间连接时间和答复时间）。 是什么让这个令人费解的是，当一个Apache服务器重复testing服务相同的内容。
Apache服务器并没有相对的分心。 我注意到唯一的区别是在testingNginx服务器时（3315.6 KB / s vs 55.5 KB / s）的“Net I / O”值。 响应时间也有“转移”（849.6 ms）的巨大贡献，而Apache服务器的“0.0”在那里。 我的第一个想法是，networkingcaching不能在Nginx服务器上工作，导致更多的数据被传输，但事实并非如此，而且httperf也不是浏览器。
我的Nginxconfiguration理论上应该能够处理这个压力testing就好了。 我怀疑数据传输量是性能差的原因。
所以我的问题是：关于一个Nginxconfiguration，可以解释这个数据传输/内容长度的差异相对于Apache服务器托pipe相同的内容？
以下是两台服务器上的httperf结果，用于1000个连接的简单10秒testing：
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 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
原来，答复长度的差异是一种方法论上的差异。 在这次testing中，我没有注意到Apache服务器正在返回所有301代码，因为这些URL正在被重写。 我不得不改变服务器的URL和path，以完全符合重写规则的执行。 之后，内容长度完美匹配，Apache服务器在这次testing中实际上比Nginx还要挣扎。