在線用戶數：用戶同時在一定時間段的在線數量
並發用戶數：某一時刻同時向服務器發送請求的用戶數
一般而言，我們習慣以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可以幫助開發者通過分布式並發壓力測試，模擬指定區域和指定數量的用戶同時訪問，提前預知網站承載力。這就是雲計算給我們帶來的便利。
-
例如OA系統使用用戶是100個,這個就是系統用戶數,該系統有一個統計查詢功能,最高峰在線50人,那么系統的並發數是多少? OA系統使用用戶是100個,這個就是系統用戶數. 最高峰值50人同時在線,只表明同時登錄了這個模塊,並不表示實際服務器承受的壓力.因為服務器承受的壓力還與具體的用戶訪問模式相關.這50人在線,有可能開着電腦溜達去了,有的看的別的模塊等等. ...
-
以下內容結合了其他網友發表的內容,首先再次表示感謝. 假設一個系統有2000個使用者(對於一般的企業系統,這個概念比較簡單,就是指數據庫中的用戶總數,但對於網站型的系統而言,相對較為復雜,一般為注冊用戶和游客的總和),也就是說,該系統的用戶總數是2000名,這個概念表示的是"系統用戶數".如果該系統具有" 在線統計"功 ...
-
與並發用戶數相關的概念還包括"並發用戶數"."系統用戶數"和"同時在線用戶數",下面用一個實際的例子來說明它們之間的差別. 假設有一個OA系統,該系統有2000個使用用戶--這就是說,可能使用該OA系統的用戶總數是2000名,這個概念就是"系統用戶數",該系統有一 ...
-
1. 背景 在做性能測試的時候,很多人都用並發用戶數來衡量系統的性能,覺得系統能支撐的並發用戶數越多,系統的性能就越好:對TPS不是非常理解,也根本不知道它們之間的關系,因此非常有必要進行解釋. 2. 術語定義 Ø 並發用戶數:指的是現實系統中操作業務的用戶,在性能測試工具中,一般稱為虛擬用戶數(Virutal User),注意並發用戶數跟注冊用戶數.在線用 ...
-
1.背景在做性能測試的時候,很多人都用並發用戶數來衡量系統的性能,覺得系統能支撐的並發用戶數越多,系統的性能就越好:對TPS不是非常理解,也根本不知道它們之間的關系,因此非常有必要進行解釋.2.術語定義Ø並發用戶數:指的是現實系統中操作業務的用戶,在性能測試工具中,一般稱為虛擬用戶數(Virutal User),注意並發用戶數跟注冊用戶數.在線用戶數有很大差 ...