我該如何解釋Apache的ab基準測試工具的結果？

Question

好的，我到處搜索，似乎無法找到詳細的資源在線如何解釋Apache的ab服務器基準測試工具的結果。我已經用我認爲是截然不同的參數進行了幾次測試，但看到了非常相似的結果（我很難認爲這意味着我的網站正在完美擴展！）。如果有人可以指點我的詳細資源，關於如何理解這個測試的結果，或者如果有人想在這裏創建一個，我認爲這對我和其他人非常有用。

Answer 1

令人沮喪的是，不是嗎？我正在嘗試做同樣的事情，看看我的新配置和配置的專用服務器與其他服務器相比如何。

我正在做的是將我目前的生產服務器（雙核4GB RAM）與新服務器（四核8GB RAM）進行比較。

由於生產服務器正在運行，我不想爲我的用戶「破壞」服務器，因此我需要並肩比較「發揮出色」。

當前比較VS新用下面的命令一個PHP頁面，只是調用phpinfo上（）：AB -kc 20 -t 60

在我目前的生產服務器上，我看到類似以下，它不可能完成的任務在給定的時間量：

Time taken for tests: 60.1234 seconds 
Complete requests: 24538 
Failed requests: 58 
(Connect: 0, Length: 58, Exceptions: 0) 
Requests per second: 408.96 [#/sec] (mean) 
Time per request: 48.905 [ms] (mean) 
Time per request: 2.445 [ms] (mean, across all concurrent requests) 

VS其完成的時間的一半量的全部測試新的服務器上執行以下操作：

Time taken for tests: 29.838791 seconds 
Complete requests: 50000 
Failed requests: 11 
(Connect: 0, Length: 11, Exceptions: 0) 
Requests per second: 1675.67 [#/sec] (mean) 
Time per request: 11.936 [ms] (mean) 
Time per request: 0.597 [ms] (mean, across all concurrent requests) 

現在，這不是一個「公平」的測試，因爲除了基準測試以外，當前的服務器正在處理20個網站。另外，它真的只測試apache & php。

把對我的更復雜的主頁一個此相同的測試，一個是「感覺」當前服務器上的慢，我看到以下內容： 當前服務器：

Time taken for tests: 60.14170 seconds 
Complete requests: 510 
Requests per second: 8.50 [#/sec] (mean) 
Time per request: 2353.497 [ms] (mean) 
Time per request: 117.675 [ms] (mean, across all concurrent requests) 

新服務器：

Time taken for tests: 60.18651 seconds 
Complete requests: 1974 
Requests per second: 32.89 [#/sec] (mean) 
Time per request: 608.092 [ms] (mean) 
Time per request: 30.405 [ms] (mean, across all concurrent requests) 

這個測試是加載一個Joomla CMS動態生成的頁面。這更像是一種「真實世界」測試。同樣，新服務器不處理當前的網站流量，所以它不是蘋果來比較蘋果。我不想更難測試，或者我在我的網站上冒着最終用戶的體驗風險。

將站點遷移到新服務器後，我打算再次執行上述測試，以便我可以看到影響我的常規站點流量對基準測試的影響。同樣的機器生產與閒置的基準測試結果。

現在，我也在考慮強調新服務器並確保它反應良好。 運行命令AB -n 50000 -c 200我看頂部命令，並看到多少CPU &內存正在使用的同時，也* F5 *荷蘭國際集團在我的瀏覽器頁面，看看我是否得到任何錯誤以及感受服務器響應需要多長時間。

我的第一個測試給了我：

Concurrency Level: 200 
Time taken for tests: 692.160011 seconds 
Complete requests: 50000 
Failed requests: 30102 
(Connect: 0, Length: 30102, Exceptions: 0) 
Write errors: 0 
Non-2xx responses: 30102 
Total transferred: 456568770 bytes 
HTML transferred: 442928962 bytes 
Requests per second: 72.24 [#/sec] (mean) 
Time per request: 2768.640 [ms] (mean) 
Time per request: 13.843 [ms] (mean, across all concurrent requests) 
Transfer rate: 644.17 [Kbytes/sec] received 

注意很高的失敗請求速率。我的apache被設置爲最多可同時處理250個請求，但我的MySQL只有175個。MySQL在這裏是失敗點。它無法處理來自Apache的所有請求。我的網頁瀏覽器頁面加載給我一個很多頁面刷新的MySQL連接錯誤頁面。所以，我把MySQL撞到了300個同步請求中（我已經做過了，但忘記重新啓動MySQL了，所以這個測試結果很不錯 - 我已經確定了一個需要的改變，並且意外地做了一個經驗證明測試驗證更改的必要性）。

下運行給我的結果如下：

Concurrency Level:  200 
Time taken for tests: 1399.999463 seconds 
Complete requests:  50000 
Failed requests:  5054 
    (Connect: 0, Length: 5054, Exceptions: 0) 
Write errors:   0 
Non-2xx responses:  5054 
Total transferred:  1016767290 bytes 
HTML transferred:  995713274 bytes 
Requests per second: 35.71 [#/sec] (mean) 
Time per request:  5599.998 [ms] (mean) 
Time per request:  28.000 [ms] (mean, across all concurrent requests) 
Transfer rate:   709.24 [Kbytes/sec] received 

這花長兩倍以上，但失敗的請求率遠低得多。基本上，服務器現在被配置爲能夠處理我網站主頁中的至少200個同時頁面瀏覽，但每頁需要5秒才能提供服務。不是很好，但比我之前得到的MySQL錯誤要好得多。

在所有這些過程中，我的服務器CPU使用率與「負載平均值」徘徊在180以上時的100％掛鉤。MySQL正在使用大約8-9％的CPU，並且沒有使用大量的RAM I已經分配了它，因爲我只是反覆敲擊相同的頁面，所以它只處理單個數據庫。 400MB的4GB +配置成長。 top顯示緩存和緩存的內存使用率約佔總可用內存的50％。所以當我用這個測試加載機器時，它並沒有接近過載點。在真實世界的數據庫使用情況下，MySQL應該佔用我分配的大部分內存，所以服務器應該在這一點上接近滿負荷。

我的下一個測試是在250個連接的「滿載」 AB -n 50000 -c 250

Concurrency Level:  250 
Time taken for tests: 1442.515514 seconds 
Complete requests:  50000 
Failed requests:  3509 
    (Connect: 0, Length: 3509, Exceptions: 0) 
Write errors:   0 
Non-2xx responses:  3509 
Total transferred:  1051321215 bytes 
HTML transferred:  1029809879 bytes 
Requests per second: 34.66 [#/sec] (mean) 
Time per request:  7212.577 [ms] (mean) 
Time per request:  28.850 [ms] (mean, across all concurrent requests) 
Transfer rate:   711.73 [Kbytes/sec] received 

這是示出類似的結果，以與適當的MySQL 200連接測試，測試apache的連接帽。我認爲這對我很好。我不喜歡7秒鐘返回一個頁面，但我想我可以通過在Joomla中緩存Joomla中的緩存或者使用已安裝但尚未被Joomla使用的Memcache來改善Joomla的性能。

試圖推動我的運氣，我想我會嘗試300同時連接。 ab -n 50000 -c 300瀏覽器顯示等待快速頁面加載。否則，結果並沒有真正的改變。

Concurrency Level:  300 
Time taken for tests: 1478.35890 seconds 
Complete requests:  50000 
Failed requests:  2266 
    (Connect: 0, Length: 2266, Exceptions: 0) 
Write errors:   0 
Non-2xx responses:  2266 
Total transferred:  1079120910 bytes 
HTML transferred:  1057241646 bytes 
Requests per second: 33.83 [#/sec] (mean) 
Time per request:  8868.215 [ms] (mean) 
Time per request:  29.561 [ms] (mean, across all concurrent requests) 
Transfer rate:   712.99 [Kbytes/sec] received 

我不知道我的這些結果的解釋是「正確的」，或者如果我失去了一些東西旅遊居停，但缺乏指導，我能找到的，這是我想出了。

我剛剛使用了結果來確保我得到了很好的響應率 - 缺乏完美的響應率關係到我，但我不知道如何以某種方式查看或重現失敗，我可以檢查它們。

每個請求的緩慢時間也與我有關，但我認爲我可以在應用程序層解決很多問題。

我相信雖然服務器會慢慢爬行，但它可以處理沉重的負載情況。

在這些基準測試之後，研究像MonYog這樣的其他性能調整工具也顯示了我目前的配置「足夠好」。

我希望有一個地方，人們發佈測試結果，我可以用硬件描述和軟件配置複製，所以我知道我是否'具有競爭力'，或者如果我有很多工作還沒有最好地利用我的設備。因此，爲什麼我張貼我的結果。

Answer 2

請注意，對於「失敗的請求」行，失敗的請求是通過比較後續請求的長度來確定的。對於動態網站，這並不意味着請求失敗！所以不要擔心失敗的請求行。

參見：http://www.celebrazio.net/tech/unix/apache_bench.html

Answer 3

在一個側面說明，AB是單線程（這是老單核CPU，如2001年的Pentium 4 OK）。

要測試承載Web服務器的多核CPU（使用多個進程的Nginx/Lighty，使用多個線程的Apache），您應該使用Weighttp（與AB兼容）。

「Weighttp -t 6」將運行6個客戶端線程（相反，「AB -t 6」將運行6秒測試）。

通過使用多個客戶端線程（與網絡服務器工作人員的數量相同 - 應與服務器的CPU核心數量相匹配），您將獲得更多相關結果。

Answer 4

在creuzerm答案之上。下面是更多的一些信息

https://serverfault.com/questions/274252/apache-ab-please-explain-the-output

關於更多線

Time per request:  7.303 [ms] (mean) 
Time per request:  0.730 [ms] (mean, across all concurrent requests) 

Answer 5

Time per request:  7.303 [ms] (mean) 
Time per request:  0.730 [ms] (mean, across all concurrent requests) 

第一個是有關的平均時間爲每併發用戶的請求之間的差別非常好的鏈接所以如果你正在對1000個請求和200個併發用戶進行測試，那麼第一個將是每個200請求的平均時間。 第二個涉及整個請求時間，這是整個1000請求的平均時間