伺服器併發處理能力——吞吐率

• 吞吐率：一般使用單位時間內伺服器處理的請求數來描述伺服器併發處理能力，單位是“reqs/s”

通過開啟Apache的mod_status模塊，查看當前伺服器的運行狀況及吞吐率。

開啟Apache的mod_status模塊的方法：

httpd.conf文件

LoadModule status_module modules/mod_status.so 去掉前面的#，併在文件底部添加：

<location /server-status>
　　SetHandler server-status
　　Order Deny,Allow
　　Deny from nothing
　　Allow from all
</location>
ExtendedStatus On

重啟伺服器。

瀏覽器輸入：http://localhost/server-status

159 requests/sec是此時的吞吐率。5 requests是此時的併發用戶數。

• 併發用戶數：在某一時刻同時向伺服器發送請求的用戶總數。

在考慮實際用戶規模的時候，我們需要考慮到，用戶訪問Web站點通常使用瀏覽器，而瀏覽器在下載一個網頁以及網頁中的多個組件時，採用多線程的併發下載方式，但是對於同一個功能變數名稱下URL的併發下載數是有最大限制的，具體限制視瀏覽器的不同而不同。以下是在HTTP/1.1下不同瀏覽器的併發數：

所以，伺服器所支持的最大併發數，具體到真實的用戶，可能並不是一對一的關係，一個真實的用戶可能會給伺服器帶來兩個或更多的併發用戶數壓力。

從web伺服器角度來看，web伺服器一般會限制同時服務的最多用戶數，比如Apache的MaxClients參數，所以實際的併發用戶數，有時候大於伺服器的併發連接數，而多出的用戶請求，則在伺服器內核的數據接收緩衝區中等待處理，所以這些請求在用戶看來處於阻塞狀態。

• 請求等待時間

假設併發用戶數為100，這時伺服器一般會採用多進程或多線程的併發模型，通過多個執行流來同時處理多個併發用戶的請求，而多執行體系的設計原則是輪流交錯使用CPU時間片，所以每個執行流花費的時間都被拉長。對每個用戶而言，每個請求的平均等待時間會增加；對伺服器而言，如果併發策略得當，每個請求的平均處理時間可能減少。、

• ab壓力測試

ab可以直接在Web伺服器本地發起測試請求。

ab進行一切測試的本質都是基於HTTP的。

[root@iZ23elnq9m3Z bin]# ./ab -n1000 -c400 http://www.abc.com/index.php?c=customer&a=index&area=-1&signtime=36&status=0
[1] 12341
[2] 12342
[3] 12343
[4] 12344
[root@iZ23elnq9m3Z bin]# This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.myidns.com (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:        Apache
Server Hostname:        www.abc.com
Server Port:            80

Document Path:          /index.php?c=customer
Document Length:        0 bytes

Concurrency Level:      400
Time taken for tests:   3.283 seconds
Complete requests:      1000
Failed requests:        0
Non-2xx responses:      1000
Total transferred:      360000 bytes
HTML transferred:       0 bytes
Requests per second:    304.64 [#/sec] (mean)
Time per request:       1313.040 [ms] (mean)
Time per request:       3.283 [ms] (mean, across all concurrent requests)
Transfer rate:          107.10 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   14  83.8      0    1000
Processing:     8  742 980.4    254    3272
Waiting:        1  741 980.5    252    3272
Total:         43  756 981.4    255    3278

Percentage of the requests served within a certain time (ms)
  50%    255
  66%    264
  75%   1242
  80%   1539
  90%   3099
  95%   3190
  98%   3248
  99%   3269
 100%   3278 (longest request)

[1]   Done                    ./ab -n1000 -c400 http://www.abc.com/index.php?c=customer
[2]   Done                    a=index
[3]-  Done                    area=-1
[4]+  Done                    signtime=36

 啟動ab時，傳入三個命令行參數：

-n1000 表示總請求數1000；

-c400 表示併發用戶數；

http://xxx 標簽請求的目標URL。

Requests per second:    304.64 [#/sec] (mean)  #吞吐率
Time per request:       1313.040 [ms] (mean)   #用戶平均請求等待時間
Time per request:       3.283 [ms] (mean, across all concurrent requests)  #伺服器平均請求處理時間，也是吞吐率的倒數
Transfer rate:          107.10 [Kbytes/sec] received  #這些請求在單位時間內從伺服器獲取的數據長度，可以說明伺服器在處理能力達到極限時，其出口帶寬的需求量

 對不同併發用戶數的吞吐率測試結果：

 影響上面三個指標的因素，除去伺服器的硬體配置，就是併發策略了，並不存在一個對所有性質的請求都高效的併發策略。