QPS/TPS的預估

先說標準概念：

TPS：Transactions Per Second（每秒傳輸的事物處理個數），即服務器每秒處理的事務數。TPS包括一條消息入和一條消息出，加上一次用戶數據庫訪問。（業務TPS = CAPS × 每一個呼叫平均TPS）

QPS：每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準，在因特網上，做爲域名系統服務器的機器的性能常常用每秒查詢率來衡量

 

區別：

Qps基本相似於Tps，可是不一樣的是，對於一個頁面的一次訪問，造成一個Tps；但一次頁面請求，可能產生屢次對服務器的請求，服務器對這些請求，就可計入「Qps」之中。

例如：訪問一個頁面會請求服務器3次，一次訪問，產生一個「T」，產生3個「Q」

 

併發用戶數和qps兩個概念沒有直接關係，可是若是要說qps時，必定 須要指明是多少併發用戶數下的qps，不然豪無心義，由於單用戶數的40qps和20併發用戶數下的40qps是兩個不一樣的概念。前者說明該應用能夠在一 秒內串行執行40個請求，然後者說明在併發20個請求的狀況下，一秒內該應用能處理40個請求。

 

保證天天多少pv的併發鏈接數的計算公式是：  併發鏈接數＝ pv / 統計時間(一天是86400) * 頁面衍生鏈接次數 * http響應時間 * 因數 / 服務器數量

保證4千萬pv的併發鏈接數：  (40000000pv / 86400秒 * 10個派生鏈接數 * 5秒內響應 * 5倍峯值) / 6臺服務 = 19290鏈接數

 

採用8/2原則。即80%的請求訪問在20%的時間內到達。此時根據系統pv測算出qps值 
峯值qps=（總Pv * 80%）/（60*60*24*20%）。 

例如500W訪問，預估QPS: (500W * 0.8) / (60*60*24*0.2) = 400W / 17280 = 232

而後再將峯值qps/單臺能承受的最高qps，就是須要的機器數量。 機器數= 總峯值pqs/壓測單臺機子極限qps

例如一臺機器的最高QPS是50，要的機器數量爲：232 / 50 = 5(臺)

 

QPS = 併發數/平均響應時間    或者   併發數 = QPS*平均響應時間
一個典型的上班簽到系統，早上8點上班，7點半到8點的30分鐘的時間裏用戶會登陸簽到系統進行簽到。公司員工爲1000人，平均每一個員上登陸簽到系統的時長爲5分鐘。能夠用下面的方法計算。
QPS = 1000/(30*60) 事務/秒
平均響應時間爲 = 5*60  秒
併發數= QPS*平均響應時間 = 1000/(30*60) *(5*60)=166.7

 

---------------------------------------------

網站按訪問QPS分類：

50QPS如下——小網站

沒什麼好說的，簡單的小網站而已，你能夠用最簡單的方法快速搭建，短時間沒有太多的技術瓶頸，只要服務器不要太爛就好。

50～100QPS——DB極限型

大部分的關係型數據庫的每次請求大多都能控制在0.01秒左右，即使你的網站每頁面只有一次DB請求，那麼頁面請求沒法保證在1秒鐘內完成100個請求，這個階段要考慮作Cache或者多DB負載。不管那種方案，網站重構是不可避免的。

300～800QPS——帶寬極限型

目前服務器大多用了IDC提供的「百兆帶寬」，這意味着網站出口的實際帶寬是8M Byte左右。假定每一個頁面只有10K Byte，在這個併發條件下，百兆帶寬已經吃完。首要考慮是CDN加速／異地緩存，多機負載等技術。

500～1000QPS——內網帶寬極限＋Memcache極限型

因爲Key/value的特性，每一個頁面對memcache的請求遠大於直接對DB的請求，Memcache的悲觀併發數在2w左右，看似很高，但事實上大多數狀況下，首先是有可能在次以前內網的帶寬就已經吃光，接着是在8K QPS左右的狀況下，Memcache已經表現出了不穩定，若是代碼上沒有足夠的優化，可能直接將壓力轉嫁到了DB層上，這就最終致使整個系統在達到某個閥值之上，性能迅速下滑。

1000～2000QPS——FORK/SELECT，鎖模式極限型

好吧，一句話：線程模型決定吞吐量。無論你係統中最多見的鎖是什麼鎖，這個級別下，文件系統訪問鎖都成爲了災難。這就要求系統中不能存在中央節點，全部的數據都必須分佈存儲，數據須要分佈處理。總之，關鍵詞：分佈。

2000QPS以上——C10K極限

儘管如今不少應用已經實現了C25K，但短板理論告訴咱們，決定網站總體併發的永遠是最低效的那個環節。