- 吞吐率：一般使用單位時間內服務器處理的請求數來描述服務器並發處理能力，單位是“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 #這些請求在單位時間內從服務器獲取的數據長度，可以說明服務器在處理能力達到極限時，其出口帶寬的需求量
對不同並發用戶數的吞吐率測試結果：
| 並發用戶數 | 吞吐率（reqs/s） | 請求等待時間（ms） | 請求處理時間（ms） |
| 1 | 266.36 | 3.754 | 3.754 |
| 2 | 506.03 | 3.952 | 1.976 |
| 5 | 530.49 | 9.425 | 1.885 |
| 10 | 530.94 | 18.935 | 1.883 |
| 20 | 539.37 | 37.081 | 1.854 |
| 50 | 530.30 | 94.285 | 1.886 |
| 100 | 538.51 | 185.697 | 1.857 |
| 150 | 322.46 | 465.169 | 3.101 |
| 200 | 538.78 | 373.285 | 1.866 |
| 300 | 81.02 | 3702.955 | 12.343 |
| 400 | 304.64 | 1313.040 | 3.283 |
| 500 | 302.55 | 1652.642 | 3.305 |
影響上面三個指標的因素，除去服務器的硬件配置，就是並發策略了，並不存在一個對所有性質的請求都高效的並發策略。