概念

併發連線數-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重新整理，將會看到刷刷一堆的請求。這裡給出某大牛收集來的不同瀏覽器產生的單站點併發連線數：

以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個併發使用者就可以了。