使用 httperf 进行 Nginx 压力测试 - 与 Apache 服务器的大量数据传输差异

使用 httperf 进行 Nginx 压力测试 - 与 Apache 服务器的大量数据传输差异

我正在四核 Nginx 服务器上运行一个简单的 httperf 压力测试,测试针对的是 HTML/PHP 文档。连接速率过高很快会导致连接和响应时间过长(请参见下面结果中的中位连接时间和回复时间)。令人费解的是,当在提供相同内容的 Apache Web 服务器上重复测试时。

Apache 服务器相对来说并不费力。我注意到的唯一区别是“Net I/O”值,测试 Nginx 服务器时,该值要大得多(3315.6 KB/s vs 55.5 KB/s)。响应时间也有很大一部分来自“传输”(849.6 毫秒),而 Apache 服务器的该值是“0.0”。我首先想到的是 Nginx 服务器上的 Web 缓存不起作用,导致传输了更多数据,但事实并非如此,而且 httperf 也不是浏览器。

从理论上讲,我的 Nginx 配置应该能够很好地处理这个压力测试。我怀疑数据传输量是导致性能不佳的原因。

所以我的问题是:与托管相同内容的 Apache 服务器相比,Nginx 配置如何解释数据传输/内容长度的差异?

以下是在两个服务器上进行 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

阿帕奇

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

答案1

事实证明,响应长度的差异是方法论上的。我没有注意到 Apache 服务器在这次测试中返回了所有 301 代码,因为 URL 被重写了。我不得不更改服务器 URL 和路径,以完全匹配重写规则所强制执行的内容。之后,内容长度完美匹配,Apache 服务器在这次测试中实际上比 Nginx 更吃力。

相关内容