併發鏈接數、請求數、併發用戶數

-----提供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個併發用戶就能夠了。