什么是並發連接數、請求數、並發用戶數?
概念
並發連接數-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個並發用戶就可以了。