先說標准概念：
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，但短板理論告訴我們，決定網站整體並發的永遠是最低效的那個環節。