-----提供AD\Exchange\Lync\Sharepoint\CRM\SC\O365等微軟產品實施及外包，QQ:185426445.電話18666943750
併發連接數、請求數、併發用戶數
概念
併發連接數-SBC（Simultaneous Browser Connections）
併發連接數指的是客戶端向服務器發起請求，並建立了TCP連接。每秒鐘服務器鏈接的總TCP數量，就是併發連接數。
請求數-QPS（Query Per Second）/RPS（Request Per Second）
請求數有2個縮寫，可以叫QPS也可以叫RPS。單位是每秒多少請求。Query=查詢，也相當於請求。請求數指的是客戶端在建立完連接後，向http服務發出GET/POST/HEAD數據包，服務器返回了請求結果後有兩種情況：
http數據包頭包含Close字樣，關閉本次TCP連接；
http數據包頭包含Keep-Alive字樣，本次連接不關閉，可繼續通過該連接繼續向http服務發送請求，用於減少TCP併發連接數。
服務器性能怎麼測？
通常情況下，我們測試的是QPS，也就是每秒請求數。不過爲了衡量服務器的總體性能，測試時最好一起測試併發連接數和請求數。
測試原理
測試併發連接數採用每個併發1請求，多個併發進行；
測試請求數採用多併發、每個併發多個請求進行，總的請求數將會=併發數*單併發請求數，需要注意的是不同的併發和單併發請求數得出來的結果會不同，因此最好測試多次取平均值。
區分請求數意義何在？
大家打開Chrome瀏覽器，按下F12，切換到Network選項卡，隨便打開一個網頁，按下F5刷新，將會看到刷刷一堆的請求。這裏給出某大牛收集來的不同瀏覽器產生的單站點併發連接數：
| 瀏覽器 | HTTP 1.1 | HTTP 1.0 |
|---|---|---|
| IE 6,7 | 2 | 4 |
| IE 8 | 6 | 6 |
| Firefox 2 | 2 | 8 |
| Firefox 3 | 6 | 6 |
| Safari 3, 4 | 4 | 4 |
| Chrome 1,2 | 6 | ? |
| Chrome 3 | 4 | 4 |
| Opera 9.63,10.00alpha | 4 | 4 |
以Chrome爲例，假設服務器設置的是Close(非持久連接)，瀏覽器打開網頁後，首先打開4個併發加載數據，在這些請求完成後關閉4個連接，再打開4個併發連接加載數據。也就是說，並不是這個網頁有100個請求就會產生100併發，而是4個併發連接並行。假設服務器設置的是keep-alive(持久連接)，瀏覽器打開網頁後，首先打開4個併發加載數據，在這些請求完成後不關閉連接，而是繼續發出請求，節約重新打開連接的時間。【前面紅色標出的是keep-alive持久連接和close非持久的區別，持久連接除了Squid(這貨用了特殊方法在http 1.0實現持久連接)，只在http 1.1協議中有效！】
主機到底能多少人在線？
看到這裏相信你已經知道答案了，這個問題無解，根據網頁的內容大小和單網頁的請求數和服務器的配置而定，這個數據的浮動值非常大所以無法測量。因此能承諾保證多少用戶在線就是坑爹的主機商！
併發用戶
併發用戶數量，有兩種常見的錯誤觀點。一種錯誤觀點是把併發用戶數量理解爲使用系統的全部用戶的數量，理由是這些用戶可能同時使用系統；還有一種比較接近正確的觀點是把用戶在線數量理解爲併發用戶數量。實際上，在線用戶不一定會和其他用戶發生併發，例如正在瀏覽網頁的用戶，對服務器是沒有任何影響的。但是，用戶在線數量是統計併發用戶數量的主要依據之一。
併發主要是針對服務器而言，是否併發的關鍵是看用戶操作是否對服務器產生了影響。因此，併發用戶數量的正確理解爲：在同一時刻與服務器進行了交互的在線用戶數量。這些用戶的最大特徵是和服務器產生了交互，這種交互既可以是單向的傳輸數據，也可以是雙向的傳送數據。
併發用戶數量的統計的方法目前還沒有準確的公式，因爲不同系統會有不同的併發特點。例如OA系統統計併發用戶數量的經驗公式爲：使用系統用戶數量*(5%~20%)。對於這個公式是沒有必要拘泥於計算的結果，因爲爲了保證系統的擴展空間，測試時的併發用戶數量要稍微大一些，除非是要測試系統能承載的最大併發用戶數量。舉例說明：如果一個OA系統的期望用戶爲1000個，只要測試出系統能支持200個併發用戶就可以了。