QPS = req/sec = 請求數/秒

【QPS計算PV和機器的方式】

QPS統計方式 [一般使用 http_load 進行統計]
QPS = 總請求數 / ( 程序總數 *   請求時間 )
QPS: 單個程序每秒請求伺服器的成功次數

單臺伺服器每天PV計算
公式1：每天總PV = QPS * 3600 * 6
公式2：每天總PV = QPS * 3600 * 8

伺服器計算
伺服器數量 =   ceil( 每天總PV / 單臺伺服器每天總PV )

【峰值QPS和機器計算公式】

原理：每天80%的訪問集中在20%的時間裡，這20%時間叫做峰值時間
公式：( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS)

問：每天300w PV 的在單臺機器上，這臺機器需要多少QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

問：如果一臺機器的QPS是58，需要幾臺機器來支援？
答：139 / 58 = 3

關於併發使用者數和QPS，自己一直被這兩個概念糾結，閱讀了一下相關資料，總結如下：併發使用者數和QPS兩個概念沒有直接關係，但是如果要說QPS時，一定需要指明是多少併發使用者數下的QPS，否則豪無意義，因為單使用者數的40QPS和20併發使用者數下的40QPS是兩個不同的概念。前者說明該應用可以在一秒內序列執行40個請求，而後者說明在併發20個請求的情況下，一秒內該應用能處理40個請求，當QPS相同時，越大的併發使用者數，代表了網站併發處理能力越好。對於當前的web伺服器，其處理單個使用者的請求肯定戳戳有餘，這個時候會存在資源浪費的情況（一方面該伺服器可能有多個cpu，但是隻處理單個程序，另一方面，在處理一個程序中，有些階段可能是IO階段，這個時候會造成CPU等待，但是有沒有其他請求程序可以被處理）。而當併發數設定的過大時，每秒鐘都會有很多請求需要處理，會造成程序（執行緒）頻繁切換，反正真正用於處理請求的時間變少，每秒能夠處理的請求數反而變少，同時使用者的請求等待時間也會變大，甚至超過使用者的心理底線。所以在最小併發數和最大併發數之間，一定有一個最合適的併發數值，在併發數下，QPS能夠達到最大。但是，這個併發並非是一個最佳的併發，因為當QPS到達最大時的併發，可能已經造成使用者的等待時間變得超過了其最優值，所以對於一個系統，其最佳的併發數，一定需要結合QPS，使用者的等待時間來綜合確定。

圖1 併發使用者數，QPS，使用者平均等待時間（響應時間關係圖）

上面這張圖是應用其他人的關於併發使用者數，QPS，使用者平均等待時間的一張關係圖，對於實際的系統，也應該是對於不同的併發數，進行多次測試，獲取到這些數值後，畫出這樣一張圖出來，以便於分析出系統的最佳併發使用者數。