我們常用QPS（Query Per Second，每秒處理請求數(shù)）來衡量一個web應(yīng)用的吞吐率，解決每秒數(shù)萬次的高并發(fā)場景，這個指標非常關(guān)鍵。
舉個栗子：假設(shè)一個業(yè)務(wù)請求平均為100ms，同時系統(tǒng)內(nèi)有20臺apache web服務(wù)器，MaxClients（apache的最大連接數(shù)）設(shè)置為500，那么理論QPS峰值就是20*500/0.1=100000（理論與實際肯定有差異）。
這系統(tǒng)貌似理論上來說很強大1秒鐘處理100000個請求，實際當然沒有這么理想。在高并發(fā)的實際場景下，機器都處于高負載的狀態(tài)，在這個時候平均響應(yīng)時間會被大大增加。
就Web服務(wù)器而言，Apache打開了越多的連接進程，CPU需要處理的上下文切換也越多，額外增加了CPU的消耗，然后就直接導致平均響應(yīng)時間增加。因此上述的MaxClient數(shù)目，要根據(jù)CPU、內(nèi)存等硬件因素綜合考慮，絕對不是越多越好?？梢酝ㄟ^Apache自帶的abench來測試一下，取一個合適的值。然后，我們選擇內(nèi)存操作級別的存儲的Redis，在高并發(fā)的狀態(tài)下，存儲的響應(yīng)時間至關(guān)重要。網(wǎng)絡(luò)帶寬雖然也是一個因素，不過，這種請求數(shù)據(jù)包一般比較小，一般很少成為請求的瓶頸。負載均衡成為系統(tǒng)瓶頸的情況比較少，在這里不做討論。
那么問題來了，假設(shè)我們的系統(tǒng)，在5w/s的高并發(fā)狀態(tài)下，平均響應(yīng)時間從100ms變?yōu)?50ms（實際情況，甚至更多）：
20*500/0.25 = 40000 （4萬QPS）
于是，我們的系統(tǒng)剩下了4w的QPS，面對5w每秒的請求，中間相差了1w。
舉個例子，高速路口，1秒鐘來5部車，每秒通過5部車，高速路口運作正常。突然，這個路口1秒鐘只能通過4部車，車流量仍然依舊，結(jié)果必定出現(xiàn)大塞車。（5條車道忽然變成4條車道的感覺）
同理，某一個秒內(nèi)，20*500個可用連接進程都在滿負荷工作中，卻仍然有1萬個新來請求，沒有連接進程可用，系統(tǒng)陷入到異常狀態(tài)也是預(yù)期之內(nèi)。
