從壓測場景角度講，壓測有以下3個場景
80~20原則：但是在現實生活中，以上兩種情況發生的概率很小。根據統計學原理，採用80~20原則計算併發使用者數。剛開始看感覺還蠻有意思，但是這算出來的是每秒鐘使用者訪問系統頁面的數量，系統有那麼多頁面呢，你要不要除以頁面數計算出平均乙個頁面的併發數？乙個頁面也很多功能呢？再除以功能數？乙個功能也許會發多個http請求？還要乘以請求數？扯淡，太扯淡了，通過pv根本就算不出你壓測的目標。至少算不出你單場景（某個介面）的目標併發使用者數。8000*0.8/（8*60*60*0.2）=1.11，即每秒中有兩個使用者併發。
例子： 10pv的併發連線數： (100000pv / 86400秒 * 50個派生連線數 * 1秒內響應 * 5倍峰值) /
1臺web伺服器 = 289 併發連線數
這個大牛還給了頁面衍生連線數（每個頁面相同嗎？你每個頁面都統計一下？累死你，再說了，頁面衍生再多，跟我壓測的介面有毛關係，50個人同時訪問登入介面，登入介面可能會請求一些，css，這些請求我關心嗎？我的併發是50*n個頁面衍生請求嗎？乘個屁，這個時候我登入介面的併發就是50），http響應時間（使用1秒，這不扯淡嗎，不同的http請求響應時間差距大了），因數一般使用5（怎麼來的，想出來的啊，我擦）
經常有人qq上問我，領導讓我測試效能，我該壓測多少併發；首先這種說法就不對，併發和響應時間是一起出現的。2s的響應時間支援的併發和10s響應時間支援的併發能一樣嗎？
誰讓你測併發，你先問他，在小於多少響應時間的前提下，測試最大併發使用者數；
回過頭來再說，領導就是一句話，測併發，其實領導的意思是，你在x秒的響應時間前提下，測出來系統支援的最大併發使用者數是多少，把這個丟給領導就行了。
領導一句話，測效能。那你就更單純點，測下系統某功能最大tps吧，比併發和響應時間客觀一些。
結論是什麼？我找不到通過pv能夠計算出來併發的途徑。但是系統上線後，隨著業務的發展，使用者的增多，併發的增加，系統有可能會崩潰對吧。這種鍋你想背嗎？不想，怎麼避免？監控，通過監控伺服器各項指標（cpu、memory等），設定閾值，比如cpu超過50%，就該做出相應的動作了，是加伺服器硬體，還是系統調優。
這是目前水平的認知，歡迎你來打我的假。
關於併發使用者數的思考 通過PV量換算併發
首先介紹一下pv量 pv 訪問量 即page view,即頁面瀏覽量或點選量，使用者每次重新整理即被計算一次。uv 獨立訪客 即unique visitor,訪問您 的一台電腦客戶端為乙個訪客。00 00 24 00內相同的客戶 端只被計算一次。ip 獨立ip 即internet protocol,...
Pv和併發的換算
pv和併發的換算 l 併發數 pv pv統計時間，換算成s，一天是86400s 頁面鏈結次數，包括外部的js css等，一般可用10 http響應時間，一般可用1或者更少 因數，一般用5 web伺服器數量 l pv 併發使用者數 pv統計時間，換算成s，一天是86400s 頁面鏈結次數，包括外部的j...
PV和併發 以及計算web伺服器的數量的方法
幾個概念 流量是指 的訪問量，用來描述訪問 的使用者數量以及使用者所瀏覽的網頁數量等指標，常用的統計指標包括 的獨立使用者數量 總使用者數量 含重複訪問者 網頁瀏覽數量 每個使用者的頁面瀏覽數量 使用者在 的平均停留時間等。綜合瀏覽量 pv 指一定時間範圍內頁面瀏覽量或點選量，使用者每次重新整理即被...