有人能解釋一下這些ApacheBench結果的含義嗎？

Question

我想弄清楚如何使用ApacheBench和基準我的網站。我安裝了默認的站點項目（它是ASP.NET MVC，但如果你不是.NET的人，請不要停下來閱讀）。

我沒有改變任何東西。添加新項目。將配置設置爲RELEASE。無調試運行。 （所以它處於LIVE模式）。是的，這是與內置的網絡服務器，而不是生產級IIS或Apache或其他。

所以這裏的結果： -

C:\Temp>ab -n 1000 -c 1 http://localhost:50035/ 
This is ApacheBench, Version 2.3 <$Revision: 655654 $> 
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ 
Licensed to The Apache Software Foundation, http://www.apache.org/ 

Benchmarking localhost (be patient) 
Completed 100 requests 
Completed 200 requests 
Completed 300 requests 
Completed 400 requests 
Completed 500 requests 
Completed 600 requests 
Completed 700 requests 
Completed 800 requests 
Completed 900 requests 
Completed 1000 requests 
Finished 1000 requests 


Server Software:  ASP.NET 
Server Hostname:  localhost 
Server Port:   50035 

Document Path:  /
Document Length:  1204 bytes 

Concurrency Level:  1 
Time taken for tests: 2.371 seconds 
Complete requests:  1000 
Failed requests:  0 
Write errors:   0 
Total transferred:  1504000 bytes 
HTML transferred:  1204000 bytes 
Requests per second: 421.73 [#/sec] (mean) 
Time per request:  2.371 [ms] (mean) 
Time per request:  2.371 [ms] (mean, across all concurrent requests) 
Transfer rate:   619.41 [Kbytes/sec] received 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  0 0 1.1  0  16 
Processing:  0 2 5.5  0  16 
Waiting:  0 2 5.1  0  16 
Total:   0 2 5.6  0  16 

Percentage of the requests served within a certain time (ms) 
    50%  0 
    66%  0 
    75%  0 
    80%  0 
    90%  16 
    95%  16 
    98%  16 
    99%  16 
100%  16 (longest request) 

C:\Temp> 

現在，我不知道到底是什麼我應該看。

首先，我在一秒鐘之後請求數。因此，如果我們有要求處理300次/秒的要求，那麼這是說它處理和每秒421平均需求？

其次，添加更多併發的原因是什麼？如果，如果我在1個併發上有1000次點擊，那麼2個併發上的500個不同？是否要測試是否有阻止其他請求的代碼？

最後，有什麼重要的，我從結果中錯過了，我應該注意到？

謝謝:)

Answer 1

什麼是增加更多的 併發的原因嗎？如在，如果我有1000個點擊 在1併發，如何不同 到500併發2？如果有任何代碼阻止其他 請求，是否要測試 ？

這是一個有點，是的：你的應用程序可能會做併發可能帶來麻煩的事情。

幾個例子：

• 頁面試圖訪問一個文件 - 在這個過程中鎖定它;這意味着如果另一個頁面必須訪問同一個文件，它必須等到第一個頁面處理完畢。
• 完全一樣的數據庫訪問：如果一個頁面被寫入到數據庫中，有某種鎖定mecanisms的（無論是基於表格或基於行的，或什麼的，這取決於你的DBMS）

測試併發性是好的......只要你的網站永遠不會有多個用戶在同一時間;這是相當不現實的，我希望爲你。

你必須考慮有多少用戶會在現場同時進行生產 - 並調整併發性;只記得，5個用戶在同一時間在您的網站並不意味着你必須用5 AB併發測試：

• 真正的用戶會等待每個請求之間的幾秒鐘（時間閱讀頁面，點擊一個鏈接，...）
• ab不會等待：每次頁面加載（即一個請求完成），它會啓動另一個請求！

此外，其他兩件事情：

• AB只測試一個網頁 - 真正的用戶會瀏覽整個網站，這可能會導致併發問題，你就不會在測試只有一個頁面
• ab只加載一個頁面：它不請求外部資源（認爲CSS，圖像，JS，...）;這意味着當您的網站投入生產時，即使不是真的很貴，也會有很多其他請求。

一點題外話：當你想，如果事情你做了測量AB是非常好的：你可能想看看其他的工具，它可以做更完整的測試，像siege，Jmeter，或OpenSTA是否優化您的網頁;但如果你想模擬你的網站的「真實」使用情況，這些更適合。

Answer 2

是的，如果您想知道您的網站每秒可以提供多少請求，請查看「每秒請求數」行。 在你的情況下，它真的很簡單，因爲你運行的併發性爲1.每個請求平均只需2.371ms。這些人中的421人一個接一個地消耗1秒。

你真的應該玩併發一點點，以準確衡量你的網站的容量。 由於多個請求由IIS並行處理，因此預計吞吐量會增加一定程度的併發性。 例如如果你的服務器有多個CPU /內核。另外，如果頁面依賴於外部IO（中間層服務或DB調用），則CPU可以在一個請求上工作，而另一個則在等待IO完成。 在某個點上，請求/秒將平穩，併發性增加，並且您將看到延遲增加。因爲服務器必須投入更多資源來處理所有這些併發請求，所以您的吞吐量（req/sec）會降低，從而進一步提高併發性。

所有這一切說，大部分請求返回大約2ms。這非常快，所以我猜測在數據庫或中間層調用方面沒有多少進展，並且在測試運行時系統可能在cpu上最大化（或者出現問題，並且速度很快。你確定ab得到你想要的響應頁面，即你認爲你正在測試的頁面大小是1204字節？）。 這引出了另外一點：ab本身也會消耗CPU，特別是一旦你達到了併發性。所以你想在另一臺機器上運行ab。

此外，應你的網站做外部調用中間層服務或數據塊，你要調整你的machine.config優化線程數IIS分配：http://support.microsoft.com/default.aspx?scid=kb;en-us;821268

和一點點瑣事：所用的時間統計信息以〜16ms的增量進行，因爲這似乎是所用定時器的粒度。即80％的回覆不需要0ms，他們花了一些時間< 16ms。