qps=併發數/rt 或者 併發數=qps*rt
舉個栗子：
假設公司每天早上9點到10點1個小時內都有員工要上廁所，公司有3600個員工，平均每個員工上廁所時間為10分鐘，我們來計算一下。
qps = 3600/60*60 1
rt = 10*60 600秒
併發數 = 1 * 600 600
這樣就意味著如果想達到最好的蹲坑體驗，公司需要600個坑位來滿足員工需求，否則的話上廁所就要排隊等待了。
按照qps=併發數/rt公式，假設我們現在是單執行緒的場景，那麼qps公式應該是這樣：qps=1/rt，實際上rt應該=cpu time + cpu wait time，如果將執行緒數提高到2，那麼qps=2/(cpu time + cpu wait time)，那麼是否意味著我們只要單純提高執行緒數就能提高qps呢？
假設cpu time是49ms，cpu wait time是200ms，那麼qps=1000ms/249ms=4.01，這裡200ms的wait時間我們可以認為cpu一直處於等待狀態啥也沒乾，理論上來說200ms還可以接受200/49≈4個請求，不考慮上下文切換和其他開銷的話，可以認為匯流排程數=(200+49)/49=5，如果再考慮上cpu多核和利用率的問題，我們大致可以認為：最佳執行緒數=rt/cpu time * cpu核心數 * cpu利用率
那麼最大qps公式推導為：
最大qps=最佳執行緒數*單執行緒qps=（rt/cpu time * cpu核心數 * cpu利用率）*（1/rt) = cpu核心數*cpu利用率/cpu time
那麼這樣是否意味著我們只要不停增加cpu核心數就能無限提高qps呢?
實際上隨著請求數量的增加，帶來大量的上下文的切換、gc和鎖變化。qps更高，產生物件越多，gc越頻繁，cpu time和利用率都受到影響，尤其在序列的時候，鎖自旋、自適應、偏向等等也成為影響par的因素。
總結，為了提公升達到最好的效能，我們需要不斷的進行效能測試，調整小城池大小，找到最合適的引數來達到提高效能的目的。
深入淺出QPS RT和最佳執行緒數
qps是每秒鐘處理完請求的次數。這裡的請求不是指乙個查詢或者資料庫查詢，是包括乙個業務邏輯的整個流程，也就是說每秒鐘響應的請求次數。響應時間即rt，處理一次請求所需要的平均處理時間。對於rt，客戶端和服務端是大不相同的，因為請求從客戶端到服務端，需要經過廣域網，所以客戶端rt往往遠大於服務端rt，同...
深入淺出QPS RT和最佳執行緒數
深入淺出qps rt和最佳執行緒數 阿姆達爾定律 qps是每秒鐘處理完請求的次數。這裡的請求不是指乙個查詢或者資料庫查詢，是包括乙個業務邏輯的整個流程，也就是說每秒鐘響應的請求次數。響應時間即rt，處理一次請求所需要的平均處理時間。對於rt，客戶端和服務端是大不相同的，因為請求從客戶端到服務端，需要...
併發工具類（三）控制併發執行緒數的Semaphore
簡介 semaphore 訊號量 是用來控制同時訪問特定資源的執行緒數量，它通過協調各個執行緒，以保證合理的使用公共資源。很多年以來，我都覺得從字面上很難理解semaphore所表達的含義，只能把它比作是控制流量的紅綠燈，比如xx馬路要限制流量，只允許同時有一百輛車在這條路上行使，其他的都必須在路口...