隨筆：今天筆者給大家分享一下自己收集的關於併發量統計比較好的文章，注意是收集來的，不是筆者自寫，在這裡向原著致敬！

普通的Web系統,關於併發量與使用者數的關係計算如下:

 1.單臺伺服器最高併發數2000,這是業內的大牛通過各種架構/優化/技術實現的.  我們水平沒那麼高, 但200併發 絕對是沒問題的.

2.單個請求的處理時間, 理論上的極值為70ms(這是內網Web伺服器訪問資料庫伺服器的網路時間),  我們水平沒那麼高, 但也絕對可以在500ms內完成一次請求(不包括使用者到Web伺服器的網路時間)

3.根據以上, 單臺伺服器 每秒可響應 400個請求.

4.每小時響應 144W 請求.

5.每天的響應不能簡單 乘以24, 因為正常系統,晚上沒人用, 電子商務通常在早10,下午14點,晚上19點附近會有高峰期. 根據經驗,高峰期 一小時的請求量是每天請求量的十分之一.

   即每天響應 1440W請求.

6.每個頁面平均有2個請求(Ajax會導致額外的請求), 靜態資源請求不計入,這個只跟網路有關,即,每天響應720W個頁面

7.根據經驗,在網站發生實質性業務的使用者 ,平均開啟100個頁面(這個是往高了說的).  即 單臺伺服器 每天可支援 7.2W個實質交易.

8.根據經驗 每天 登入使用者數是交易使用者數的十倍,但頁面開啟數極少,通常是1-10,  這個忽略.  即, 單臺伺服器每天 有 72W個登入使用者.

9.根據經驗,註冊使用者是每天登入使用者的10倍(如果沒有刷殭屍使用者的話), 單臺伺服器可以為 720W個註冊使用者服務.

10.使用負載均衡後,通常負載均衡伺服器 會是 2/4/8/16 這個規模 , 通常不會超過16.  即 16個負載均衡伺服器 可 服務 1.15億使用者(這個至少也是京東的級別了)

 

最後: 如果使用者數超過以上計算,或者業務複雜度導致無法實現200併發(如:複雜業務,幾十個流程),那麼 我們會根據實際專案情況 採取 其他技術手段來提高 伺服器叢集的響應能力

如: 快取memcache, 更高速的資料庫mongo/redis,動靜分離CDN,資料庫分庫/分表

再比如: 部分關鍵節點採用Java進行處理, 這裡並不是說Java就比PHP好, 但在極限速度響應上,Java的確比PHP快, Java程式駐留記憶體啊~~~

 

網站併發量的計算方法

PV是什麼：

PV是page view的簡寫。PV是指頁面的訪問次數，每開啟或重新整理一次頁面，就算做一個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。因為我關心的是應用程式處理業務的能力。 

 

實際經驗：

1、根據實際經驗，採用兩臺常規配置的機架式伺服器，配置是很常見的配置，例如一個4核CPU+4G記憶體+伺服器SAS硬碟。

2、個人武斷的認為在伺服器CPU領域Intel的CPU要優於AMD的CPU，有反對的就反對吧，我都說我武斷了（請看CPU效能比較），不要太相信AMD的廣告，比較CPU效能簡單辦法就是比價格，不要比頻率與核心數，價格相差不多的效能也相差不多。

3、硬碟的效能很重要，由其是資料庫伺服器。一般的伺服器都配1.5萬轉的SAS硬碟，高階一點的可以配SSD固態硬碟，效能會更好。最最最最重要的指標是“隨機讀寫效能”而不是“順序讀寫效能”。（本例還是配置最常見的1.5萬轉的SAS硬碟吧）

4、一臺伺服器跑Tomcat執行j2ee程式,一臺伺服器跑MySql資料庫,程式寫的中等水平(這個真的不好量化)，是論壇型別的應用(總有回帖,不太容易做快取,也無法靜態化)。

5、以上軟硬體情況下，是可以承受100萬PV/每天的。(已留有餘量應對突然的訪問高峰)

 

注意機房的網路頻寬：

有人說以上條件我都滿足了，但實際效能還是達不到目標。這時請注意你對外的網路的頻寬，在國內伺服器便宜但頻寬很貴，很可能你在機房是與大家共享一條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頻寬基本可以滿足要求。

以上是假設每個頁面20k位元組，基本不包含圖片，要是包含圖片就更大了，10M頻寬也不能滿足要求了。你自已計算吧。

 

附：效能測試基本概念
--------------------------------------------------------------------------------------- 
基本概念： 
Throughput（吞吐量）：按照常規理解網路吞吐量表示在單位時間內通過網路卡資料量之和，其中即包括本機網路卡傳送出去的資料量也包括本機網路卡接收到的資料量。 一個100Mb(位)的雙工網路卡，最大傳送資料的速度是12.5M位元組/s ， 最大接收資料的速度是12.5M位元組/s， 可以 同時 收發 資料。 
併發使用者數：是同時執行操作的使用者(執行緒數)。 
響應時間：從請求發出到收到響應花費的時間 。

QPS - Queries Per Second  每秒處理的查詢數（如果是資料庫，就相當於讀取）
TPS - Transactions Per Second  每秒處理的事務數(如果是資料庫，就相當於寫入、修改)
IOPS，每秒磁碟進行的I/O操作次數

例如對某個資料庫測試，分開兩次測QPS與TPS。
QPS（讀取）值總是高於TPS(寫、改)，並且有倍率關係，因為：
1、資料庫對查詢可能有快取。
2、機械硬碟或SSD硬碟的讀就是比寫快。 

 

系統的平均併發使用者數和併發數峰值如何估算

一、經典公式1：

   一般來說，利用以下經驗公式進行估算系統的平均併發使用者數和峰值資料

 

  1）平均併發使用者數為 C = nL/T

  2）併發使用者數峰值 C‘ = C + 3*根號C

    C是平均併發使用者數，n是login session的數量，L是login session的平均長度，T是值考察的時間長度

    C’是併發使用者數峰值

 

  舉例1，假設系統A，該系統有3000個使用者，平均每天大概有400個使用者要訪問該系統（可以從系統日誌從獲得），對於一個典型使用者來說，一天之內使用者從登陸到退出的平均時間為4小時，而在一天之內，使用者只有在8小時之內會使用該系統。

  那麼，

  平均併發使用者數為：C = 400*4/8 = 200

  併發使用者數峰值為：C‘ = 200 + 3*根號200 = 243

 

  舉例2， 某公司為其170000名員工設計了一個薪酬系統，員工可進入該系統查詢自己的薪酬資訊，但並不是每個人都會用這個系統，假設只有50%的人會定期用該系統，這些人裡面有70%是在每個月的最後一週使用一次該系統，且平均使用系統時間為5分鐘。

  則一個月最後一週的平均併發使用者數為（朝九晚五）：

  n = 170000*0.5*0.7/5 = 11900

  C= 11900*5/60/8 = 124

 

  吞吐量計算為：F = Vu * R / T 單位為個/s

    F為事務吞吐量，Vu為虛擬使用者數個數，R為每個虛擬使用者發出的請求數，T為處理這些請求所花費的時間

 

二、通用公式2：

  對絕大多數場景，我們用（使用者總量/統計時間）*影響因子（一般為3）來進行估算併發量。

  比如，以乘坐地鐵為例子，每天乘坐人數為5萬人次，每天早高峰是7到9點，晚高峰是6到7點，根據8/2原則，80%的乘客會在高峰期間乘坐地鐵，則每秒到達地鐵檢票口的人數為50000*80%/（3*60*60）=3.7，約4人/S，考慮到安檢，入口關閉等因素，實際堆積在檢票口的人數肯定比這個要大，假定每個人需要3秒才能進站，那實際併發應為4人/s*3s=12，當然影響因子可以根據實際情況增大！

 

三、根據PV計算公式：

  比如一個網站，每天的PV大概1000w，根據2/8原則，我們可以認為這1000w pv的80%是在一天的9個小時內完成的（人的精力有限），那麼TPS為：

  1000w*80%/(9*3600)=246.92個/s,取經驗因子3，則併發量應為：

  246.92*3=740

 

四、根據TPS估計：

   公式為 C = (Think time + 1)*TPS

 

五、根據系統使用者數計算：

   併發使用者數 = 系統最大線上使用者數的8%到12%