一、並發用戶數計算公式
1.例子1
1.平均並發用戶數的計算公式
C=nL / T
其中C是平均的並發用戶數，n是平均每天訪問用戶數，L是一天內用戶從登錄到退出的平均時間（操作平均時間），T是考察時間長度（一天內多長時間有用戶使用系統）
2.並發用戶數峰值計算公式
C’ ≈ C+3根號C
其中，C’指並發用戶數的峰值，C即是平均並發用戶數。該公式的得出是假設用戶的login session產生符合泊松分布而估算得到的
既然這2個公式我們來假設一下1000萬用戶可能會產生的並發情況
1.n每天訪問用戶數量=1000萬
2.假設這個服務是用作網上銀行的操作，L=一天內用戶從登陸到退出的平均時間設為（5分鍾），T假設每天早晨8點-12點，均有用戶訪問。時長16小時即960分鍾。
（這個用戶數量，我們就假定為平均每天訪問系統的用戶數，如果是總用戶數量，那么則需要先算出1000萬用戶，每天平均有多少用戶訪問。）
C=10000000*5/960=52083.33/m （即52083.33每分鍾）
3.並發用戶峰值為
C' ≈ 52083.33+3*根號52083.33=52083.33+3*228.22=52767
例子2
假設有一個OA系統，該系統有3000個用戶，平均每天大約有400個用戶要訪問該系統，對一個典型用戶來說，一天之內用戶從登錄到退出該系統的平均時間為4小時，在一天的時間內，用戶只在8小時內使用該系統。
則根據公式（1）和公式（2），可以得到：
C = 400*4/8 = 200
C’≈200+3*根號200 = 242
---------------------------------------------------------------------------------------------------
二、TPS(QPS):每秒鍾 request/事務 數量
一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要參數：QPS（TPS）、並發數、響應時間
QPS（TPS）：每秒鍾request/事務 數量
並發數： 系統同時處理的request/事務數
響應時間： 一般取平均響應時間
理解了上面三個要素的意義之后，就能推算出它們之間的關系：
QPS（TPS）= 並發數/平均響應時間 或者 並發數 = QPS*平均響應時間
一個典型的上班簽到系統，早上8點上班，7點半到8點的30分鍾的時間里用戶會登錄簽到系統進行簽到。公司員工為1000人，平均每個員上登錄簽到系統的時長為5分鍾。可以用下面的方法計算。
QPS = 1000/(30*60) 事務/秒
平均響應時間為 = 5*60 秒
並發數= QPS*平均響應時間 = 1000/(30*60) *(5*60)=166.7
或者
並發數=1000*5/30=166.7
平均響應時間為=5*60秒
QPS=166.7/5*60=0.55事務/秒
一個系統吞吐量通常由QPS（TPS）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。
首先需要了解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用戶並發就足夠了。性能測試需要一套標准化流程及測試策略，在實際測試時我們還需要考慮其它方面的問題，比如如何模擬成千上萬來自不同地區用戶的訪問場景、如何選用合適的測試軟件。
重點
1、 QPS和TPS的區別
QPS：Queries Per Second意思是“每秒查詢率”， 每秒鍾處理完請求的次數；注意這里是處理完。具體是指發出請求到服務器處理完成功返回結果。可以理解在server中有個counter，每處理一個請求加1，1秒后counter=QPS。
TPS：是TransactionsPerSecond的縮寫，也就是事務數/秒。它是軟件測試結果的測量單位。一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數，
-----------------------------------------------------
三、PV計算公式
PV是page view的簡寫。PV是指頁面的訪問次數，每打開或刷新一次頁面，就算做一個pv。
例子1
比如一個網站，每天的PV大概1000w，根據2/8原則，我們可以認為這1000w pv的80%是在一天的9個小時內完成的（人的精力有限），那么TPS為：
1000w*80%/(9*3600)=246.92個/s,取經驗因子3，則並發量應為：
246.92*3=740
例子2
你想建設一個能承受500萬PV/每天的網站嗎？ 500萬PV是什么概念？服務器每秒要處理多少個請求才能應對？如果計算呢？
計算模型：
每台服務器每秒處理請求的數量=((80%*總PV量)/(24小時*60分*60秒*40%)) / 服務器數量 。
其中關鍵的參數是80%、40%。表示一天中有80%的請求發生在一天的40%的時間內。24小時的40%是9.6小時，有80%的請求發生一天的9.6個小時當中（很適合互聯網的應用，白天請求多，晚上請求少）。
簡單計算的結果：
((80%*500萬)/(24小時*60分*60秒*40%))/1 = 115.7個請求/秒
((80%*100萬)/(24小時*60分*60秒*40%))/1 = 23.1個請求/秒
初步結論：
現在我們在做壓力測試時，就有了標准，如果你的服務器一秒能處理115.7個請求，就可以承受500萬PV/每天。如果你的服務器一秒能處理23.1個請求，就可以承受100萬PV/每天。
留足余量：
以上請求數量是均勻的分布在白天的9.6個小時中，但實際情況並不會這么均勻的分布，會有高峰有低谷。為了應對高峰時段，應該留一些余地，最少也要x2倍，x3倍也不為過。
115.7個請求/秒 *2倍=231.4個請求/秒
115.7個請求/秒 *3倍=347.1個請求/秒
23.1個請求/秒 *2倍=46.2個請求/秒
23.1個請求/秒 *3倍=69.3個請求/秒
最終結論：
如果你的服務器一秒能處理231.4--347.1個請求/秒，就可以應對平均500萬PV/每天。
如果你的服務器一秒能處理46.2--69.3個請求，就可以應對平均100萬PV/每天。
說明：
這里說明每秒N個請求，就是QPS。因為我關心的是應用程序處理業務的能力。
機房的網絡帶寬：
對外的網絡的帶寬，在國內服務器便宜但帶寬很貴，很可能你在機房是與大家共享一條100M的光纖，實際每個人可分到2M左右帶寬。再好一點5M,再好一點雙線機房10M獨享。
一天總流量：每個頁面20k字節*100萬個頁面/1024=19531M字節=19G字節，
19531M/9.6小時=2034M/小時=578K字節/s 如果請求是均勻分布的，需要5M（640K字節）帶寬（5Mb=640KB 注意大小寫，b是位，B是字節，差了8倍），但所有請求不可能是均勻分布的，當有高峰時5M帶寬一定不夠，X2倍就是10M帶寬。10M帶寬基本可以滿足要求。
---------------------