Nginx
使用 httperf 進行 Nginx 壓力測試 - 與 Apache 伺服器的大數據傳輸差異
我在四核 Nginx 伺服器上執行一個簡單的 httperf 壓力測試,指向一個 HTML/PHP 文件。大連接率很快開始經歷高連接和響應時間(請參閱下面的結果中的中值連接時間和回复時間)。令人費解的是,當測試在提供相同內容的 Apache 網路伺服器上重複時。
Apache 伺服器相對來說不會出汗。我注意到的唯一區別在於“Net I/O”值,在測試 Nginx 伺服器時該值要大得多(3315.6 KB/s vs 55.5 KB/s)。響應時間也有很大的貢獻來自“傳輸”(849.6 毫秒),而 Apache 伺服器在那裡有“0.0”。我的第一個想法是Web記憶體在Nginx伺服器上不起作用,導致傳輸更多數據,但事實並非如此,而且httperf無論如何也不是瀏覽器。
我的 Nginx 配置理論上應該能夠很好地處理這個壓力測試。我懷疑數據傳輸量是性能不佳的原因。
所以我的問題是:Nginx 配置如何解釋數據傳輸/內容長度相對於託管相同內容的 Apache 伺服器的這種差異?
以下是兩台伺服器上的 httperf 結果,用於 1000 個連接的簡單 10 秒測試:
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
事實證明,響應長度的差異是一種方法論。在此測試期間,我沒有註意到 Apache 伺服器返回所有 301 程式碼,因為 URL 正在被重寫。我必須更改伺服器 URL 和路徑以完全匹配重寫規則強制執行的內容。在那之後,內容長度完美匹配,在這個測試中,Apache 伺服器實際上比 Nginx 更困難一些。