關於並發用戶數的思考-通過PV量換算並發
首先介紹一下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秒，就是指每天的工作時間折成秒
峰值QPS/QPS/PV/UV/服務器數量／並發數／吐吞量／響應時間計算公式
QPS:
每秒查詢率(Query Per Second) ,每秒的響應請求數，也即是最大吞吐能力。
QPS = req/sec = 請求數/秒
QPS統計方式 [一般使用 http_load 進行統計]
QPS = 總請求數 / ( 進程總數 * 請求時間 )
QPS: 單個進程每秒請求服務器的成功次數
峰值QPS:
原理：每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間
公式：( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS)
PV:
訪問量即Page View, 即頁面瀏覽量或點擊量，用戶每次刷新即被計算一次
單台服務器每天PV計算
公式1：每天總PV = QPS * 3600 * 6
公式2：每天總PV = QPS * 3600 * 8
UV:
獨立訪客即Unique Visitor,訪問您網站的一台電腦客戶端為一個訪客。00:00-24:00內相同的客戶端只被計算一次
服務器數量：
機器：峰值時間每秒QPS / 單台機器的QPS = 需要的機器
機器：ceil( 每天總PV / 單台服務器每天總PV )
並發數：
並發用戶數是指系統可以同時承載的正常使用系統功能的用戶的數量
吐吞量：
吞吐量是指系統在單位時間內處理請求的數量
響應時間（RT):
響應時間是指系統對請求作出響應的時間
例子：
每天300w PV 的在單台機器上，這台機器需要多少QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
如果一台機器的QPS是58，需要幾台機器來支持？
答：139 / 58 = 3