併發數與在線用戶之間的關係

在線用戶數：用戶同時在必定時間段的在線數量

併發用戶數：某一時刻同時向服務器發送請求的用戶數

通常而言，咱們習慣以5-20的比率來推算併發用戶與在線用戶之間的關係。即，併發與在線的比例約爲5%-20%

好比，某網站存在註冊用戶數爲10W人，但同時在線最多1W人，但這1W我的，可能只有500人會瀏覽帖子，500人會進行發帖，只有這1000我的對服務器纔有交易，那咱們計算併發量的時候，就能夠以1000爲標準！

-----------------------------------------------------------------------------------------------------------------------------

昨天讀完了段念寫的《軟件性能測試過程詳解與案例剖析》一書的第一章，感受學到了很多東西，如下將該書中的我認爲是精華的一篇過來給你們一塊兒看看：

        在實際的性能測試中，常常接觸到的與併發用戶數相關的概念還包括「併發用戶數」、「系統用戶數」和「同時在線用戶數」，下面用一個實際的例子來講明它們之間的差異。

        假設有一個OA系統，該系統有2000個使用用戶——這就是說，可能使用該OA系統的用戶總數是2000名，這個概念就是「系統用戶數」，該系統有一個「在線統計」功能（系統用一個全局變量記數全部已登陸的用戶），從在線統計功能中能夠獲得，最高峯時有500人在線（這個500就是通常所說的「同時在線人數」），那麼，系統的併發用戶數是多少呢？

        根據咱們對業務併發用戶數的定義，這500就是整個系統使用時最大的業務併發用戶數。固然，500這個數值只是代表在最高峯時刻有500個用戶登陸了系統，並不表示實際服務器承受的壓力。由於服務器承受的壓力還與具體的用戶訪問模式相關。例如，在這500個「同時使用系統」的用戶中，考察某一個時間點，在這個時間上，假設其中40%的用戶在較有興致地看系統公告（注意：「看」這個動做是不會對服務端產生任何負擔的），20%的用戶在填寫複雜的表格（對用戶填寫的表格來講，只有在「提交」的時刻纔會向服務端發送請求，填寫過程是不對服務端構成壓力的），20%部分用戶在發呆（也就是什麼也沒有作），剩下的20%用戶在不停地從一個頁面跳轉到另外一個頁面——在這種場景下，能夠說，只有20%的用戶真正對服務器構成了壓力。所以，從上面的例子中能夠看出，服務器實際承受的壓力不僅取決於業務併發用戶數，還取決於用戶的業務場景。

       在實際的性能測試工做中，測試人員通常比較關心的是業務併發用戶數，也就是從業務角度關注究竟應該設置多少個併發數比較合理，所以，在後面的討論中，也是主要針對業務併發用戶數進行討論，並且，爲了方便，直接將業務併發用戶數稱爲併發用戶數。

        （1）  計算平均的併發用戶數： C = nL/T      

        （2）  併發用戶數峯值： C’ ≈ C+3根號C

         公式（1）中，C是平均的併發用戶數；n是login session的數量；L是login session的平均長度；T指考察的時間段長度。

        公式（2）則給出了併發用戶數峯值的計算方式中，其中，C’指併發用戶數的峯值，C就是公式（1）中獲得的平均的併發用戶數。該公式的得出是假設用戶的login session產生符合泊松分佈而估算獲得的。

實例：

        假設有一個OA系統，該系統有3000個用戶，平均天天大約有400個用戶要訪問該系統，對一個典型用戶來講，一天以內用戶從登陸到退出該系統的平均時間爲4小時，在一天的時間內，用戶只在8小時內使用該系統。

則根據公式（1）和公式（2），能夠獲得：

               C = 400*4/8 = 200

               C’≈200+3*根號200 = 242

        ，請你們不要見笑，雖然上面寫的都是很基礎的東西，可是對我本人來說，在尚未看這本書以前，這些概念我是特別模糊的。

 

=====================================================================

 

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

概念

併發鏈接數-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個併發加載數據，在這些請求完成後不關閉鏈接，而是繼續發出請求，節約從新打開鏈接的時間。

主機到底能多少人在線？

看到這裏相信你已經知道答案了，這個問題無解，根據網頁的內容大小和單網頁的請求數和服務器的配置而定，這個數據的浮動值很是大因此沒法測量。所以能承諾保證多少用戶在線就是坑爹的主機商！

併發用戶

併發用戶數量，有兩種常見的錯誤觀點。一種錯誤觀點是把併發用戶數量理解爲使用系統的所有用戶的數量，理由是這些用戶可能同時使用系統；還有一種比較接近正確的觀點是把用戶在線數量理解爲併發用戶數量。實際上，在線用戶不必定會和其餘用戶發生併發，例如正在瀏覽網頁的用戶，對服務器是沒有任何影響的。可是，用戶在線數量是統計併發用戶數量的主要依據之一。
併發主要是針對服務器而言，是否併發的關鍵是看用戶操做是否對服務器產生了影響。所以，併發用戶數量的正確理解爲：在同一時刻與服務器進行了交互的在線用戶數量。這些用戶的最大特徵是和服務器產生了交互，這種交互既能夠是單向的傳輸數據，也能夠是雙向的傳送數據。
併發用戶數量的統計的方法目前尚未準確的公式，由於不一樣系統會有不一樣的併發特色。例如OA系通通計併發用戶數量的經驗公式爲：使用系統用戶數量*(5%~20%)。對於這個公式是沒有必要拘泥於計算的結果，由於爲了保證系統的擴展空間，測試時的併發用戶數量要稍微大一些，除非是要測試系統能承載的最大併發用戶數量。舉例說明：若是一個OA系統的指望用戶爲1000個，只要測試出系統能支持200個併發用戶就能夠了。

 

 

===============================================================================

 

近日，Hitest在其技術博客上發表了一篇題爲《併發用戶數與TPS之間的關係》的文章，文章對TPS和併發用戶數作了詳細的解釋，並針對性能測試中系統性能的衡量維度和測試策略給出了本身的建議。Hitest是阿里巴巴技術質量部提供的一款Web&移動應用安全測試SaaS化服務平臺，旨在幫助開發者簡單快捷地進行安全測試。

在文中，做者首先對併發用戶數和TPS作了解釋：

併發用戶數：是指現實系統中操做業務的用戶，在性能測試工具中，通常稱爲虛擬用戶數(Virutal User)。併發用戶數和註冊用戶數、在線用戶數的概念不一樣，併發用戶數必定會對服務器產生壓力的，而在線用戶數只是 」掛」 在系統上，對服務器不產生壓力，註冊用戶數通常指的是數據庫中存在的用戶數。

TPS：Transaction Per Second, 每秒事務數, 是衡量系統性能的一個很是重要的指標。

做者認爲如今不少從業人員在作性能測試時，都錯誤的認爲系統能支撐的併發用戶數越多，系統的性能就越好。要理解這個問題，首先須要瞭解TPS和併發用戶數之間的關係：

TPS就是每秒事務數，可是事務是基於虛擬用戶數的，假如1個虛擬用戶在1秒內完成1筆事務，那麼TPS明顯就是1；若是某筆業務響應時間是1ms,那麼1個用戶在1秒內能完成1000筆事務，TPS就是1000了；若是某筆業務響應時間是1s,那麼1個用戶在1秒內只能完成1筆事務，要想達到1000TPS，至少須要1000個用戶；所以能夠說1個用戶能夠產生1000TPS，1000個用戶也能夠產生1000TPS，無非是看響應時間快慢。

也就是說，在評定服務器的性能時，應該結合TPS和併發用戶數，以TPS爲主，併發用戶數爲輔來衡量系統的性能。若是必需要用併發用戶數來衡量的話，須要一個前提，那就是交易在多長時間內完成，由於在系統負載不高的狀況下，將思考時間(思考時間的值等於交易響應時間)加到腳本中，併發用戶數基本能夠增長一倍，所以用併發用戶數來衡量系統的性能沒太大的意義。

做者最後作了綜述，他認爲在性能測試時並不須要用上萬的用戶併發去進行測試，若是隻須要保證系統處理業務時間足夠快，幾百個用戶甚至幾十個用戶就能夠達到目的。據他了解，不少專家作過的性能測試項目基本都沒有超過5000用戶併發。所以對於大型系統、業務量很是高、硬件配置足夠多的狀況下，5000用戶併發就足夠了；對於中小型系統，1000用戶併發就足夠了。

性能測試須要一套標準化流程及測試策略，在實際測試時咱們還須要考慮其它方面的問題，好比如何模擬成千上萬來自不一樣地區用戶的訪問場景、如何選用合適的測試軟件。性能測試對一些小的團隊來講並不是易事，不過前段時間阿里雲發佈了性能測試服務PTS，PTS能夠幫助開發者經過分佈式併發壓力測試，模擬指定區域和指定數量的用戶同時訪問，提早預知網站承載力。這就是雲計算給咱們帶來的便利。

 

 

Tags:

 

•  LoadRunner：虛擬用戶數和併發用戶數的聯繫
  例如OA系統使用用戶是100個,這個就是系統用戶數,該系統有一個統計查詢功能,最高峯在線50人,那麼系統的併發數是多少? OA系統使用用戶是100個,這個就是系統用戶數. 最高峯值50人同時在線,只代表同時登陸了這個模塊,並不表示實際服務器承受的壓力.由於服務器承受的壓力還與具體的用戶訪問模式相關.這50人在線,有可能開着電腦溜達去了,有的看的別的模塊等等. ...
•  關於併發用戶數、系統用戶數和同時在線用戶數等概念的辨析
  如下內容結合了其餘網友發表的內容,首先再次表示感謝. 假設一個系統有2000個使用者(對於通常的企業系統,這個概念比較簡單,就是指數據庫中的用戶總數,但對於網站型的系統而言,相對較爲複雜,通常爲註冊用戶和遊客的總和),也就是說,該系統的用戶總數是2000名,這個概念表示的是"系統用戶數".若是該系統具備" 在線統計"功 ...
•  「併發用戶數」、「系統用戶數」和「同時在線用戶數」的計算公式
      與併發用戶數相關的概念還包括"併發用戶數"."系統用戶數"和"同時在線用戶數",下面用一個實際的例子來講明它們之間的差異.     假設有一個OA系統,該系統有2000個使用用戶--這就是說,可能使用該OA系統的用戶總數是2000名,這個概念就是"系統用戶數",該系統有一 ...
•  併發用戶數與 TPS 之間的關係
  1. 背景 在作性能測試的時候,不少人都用併發用戶數來衡量系統的性能,以爲系統能支撐的併發用戶數越多,系統的性能就越好:對TPS不是很是理解,也根本不知道它們之間的關係,所以很是有必要進行解釋. 2. 術語定義 Ø 併發用戶數:指的是現實系統中操做業務的用戶,在性能測試工具中,通常稱爲虛擬用戶數(Virutal User),注意併發用戶數跟註冊用戶數.在線用 ...
•  併發用戶數與TPS之間的關係
  1.背景在作性能測試的時候,不少人都用併發用戶數來衡量系統的性能,以爲系統能支撐的併發用戶數越多,系統的性能就越好:對TPS不是很是理解,也根本不知道它們之間的關係,所以很是有必要進行解釋.2.術語定義Ø併發用戶數:指的是現實系統中操做業務的用戶,在性能測試工具中,通常稱爲虛擬用戶數(Virutal User),注意併發用戶數跟註冊用戶數.在線用戶數有很大差 ...