首先介紹一下pv量：
pv(訪問量)：即page view, 即頁面瀏覽量或點選量，使用者每次重新整理即被計算一次。
uv(獨立訪客)：即unique visitor,訪問您**的一台電腦客戶端為乙個訪客。00:00-24:00內相同的客戶
端只被計算一次。
ip(獨立ip)：即internet protocol,指獨立ip數。00:00-24:00內相同ip位址之被計算一次。
***************************
問題：乙個系統的日均pv量是8000，那麼併發使用者數應該是多少?
1、首先，我覺得應該考察這個系統的業務都有什麼，各個之間有什麼關聯性。這些pv都分布在**業務上。
2、如果這些pv為單一業務，那麼還要看使用者在前台的一次操作，會對伺服器端產生幾個請求。因為如果網頁中包含、js等內容，使用者一次開啟操作，會對伺服器產生多個操作。
3、我們假設使用者在前台的一次操作，僅產生一次pv。使用者併發數是指多少使用者同時對伺服器產生訪問。對此，我假設了三種訪問情況：
（1）最差情況：8000個使用者同時發起請求，那麼併發使用者數應為8000
（2）最好情況：8000個使用者在時間上均勻地發起請求。那麼併發使用者數為8000/24*60*60=0.093。折合一分鐘內之有5.5個請求，基本上就沒有併發，只是單個執行。
（3）80~20原則：但是在現實生活中，以上兩種情況發生的概率很小。根據統計學原理，採用80~20原則計算併發使用者數。
8000*0.8/（8*60*60*0.2）=1.11，即每秒中有兩個使用者併發。
可能有人會問：為什麼是每秒多少個使用者，不是每小時、每分鐘、每毫秒？
回答：我做乙個120人併發查詢的專案，響應時間最小0.047s，最大6.216s，平均0.779s。與伺服器的一次業務互動，大約需要1秒鐘。
個人感覺，以小時、分鐘做單位，時間跨度太長；以毫秒做單位，時間跨度又太短。綜上所述，以秒為單位比較合適。
4、lr設定集合點後，每次迭代中，必須全部（或部分）請求得到回覆後，才發起下次迭代。所以在迭代週期內我們只傳送了一次併發請求，我們在根據80~20原則計算得出的併發使用者數，還要乘以這個迭代週期。
例如我的查詢專案中，迭代週期大約為9秒，所以併發使用者數為1.11*9=9.99,最終得到併發使用者數為10個
個人觀點，如有不妥之處，請指正
8000是併發的訪問數，80~20原則是指80%的工作量會集中在20%的時間內完成，所以使用者訪問系統不是平均，而是集中在某一段時間內。0.8是指 取併發量的80%，0.2是指取工作時間的20%，8*60*60是指每天8小時，每小時60分，每分鐘60秒，就是指每天的工作時間折成秒
併發使用者數 吞吐量 思考時間的計算公式
二 軟體效能的幾個主要術語 響應時間 n1 a1 n2 a2 n3 a3 n4 2 併發使用者數的計算公式 系統使用者數 系統額定的使用者數量，如乙個oa系統，可能使用該系統的使用者總數是2000個，那麼這個數量，就是系統使用者數 平均併發使用者數的計算 c nl t 其中c是平均的併發使用者數，n...
併發使用者數的理解
什麼是併發使用者數，很多人都會拿這個指標來衡量乙個網路系統的好與壞，剛開始接觸loadrunner的時候，曾認為虛擬使用者就是所謂的併發使用者數，不過經過一系列的測試後，發現這種看法並不怎麼全是正確。首先，要分兩種測試情況，第一種是通過跑網頁實際業務測試，如教務系統，觀察其登陸事務，查詢事務等，第二...
TPS 併發使用者數 吞吐量關係
主要描述了在效能測試中,關於tps 併發使用者數 吞吐量之間的關係和一些計算方法。乙個系統的吞度量 承壓能力 與request對cpu的消耗 外部介面 io等等緊密關聯。單個reqeust 對cpu消耗越高，外部系統介面 io影響速度越慢，系統吞吐能力越低，反之越高。系統吞吐量幾個重要引數 qps ...