深入淺出qps、rt和最佳執行緒數
阿姆達爾定律
qps是每秒鐘處理完請求的次數。這裡的請求不是指乙個查詢或者資料庫查詢，是包括乙個業務邏輯的整個流程，也就是說每秒鐘響應的請求次數。
響應時間即rt，處理一次請求所需要的平均處理時間。對於rt，客戶端和服務端是大不相同的，因為請求從客戶端到服務端，需要經過廣域網，所以客戶端rt往往遠大於服務端rt，同時客戶端的rt往往決定著使用者的真實體驗，服務端rt往往是評估我們系統好壞的乙個關鍵因素。
在開發過程中，我們一定面臨過很多的執行緒數量的配置問題，這種問題往往讓人摸不到頭腦，往往都是拍腦袋給出乙個執行緒池的數量，但這可能恰恰是不靠譜的，過小的話會導致請求rt極具增加，過大也一樣rt也會公升高。所以對於最佳執行緒數的評估往往比較麻煩。
單執行緒場景：
假設我們的服務端只有乙個執行緒，那麼所有的請求都是序列執行，我們可以很簡單的算出系統的qps，也就是：qps = 1000ms/rt。假設乙個rt過程中cpu計算的時間為49ms，cpu wait time 為200ms，那麼qps就為1000/（49+200） = 4.01。
多執行緒場景
我們接下來把服務端的執行緒數提公升到2，那麼整個系統的qps則為：2 *（1000/(49+200)）=8.02。可見qps隨著執行緒的增加而線性增長，那qps上不去就加執行緒唄，聽起來很有道理，公式也說得通，但是往往現實並非如此，後面會聊這個問題。
從上面單執行緒場景來看，cpu wait time為200ms,你可以理解為cpu這段時間什麼都沒做，是空閒的，顯然我們沒把cpu利用起來，這時候我們需要啟多個執行緒去響應請求，把這部分利用起來，那麼啟動多少個執行緒呢？我們可以估算一下 空閒時間200ms，我們要把這部分時間轉換為cpu time,那麼就是(200+49)/49 = 5.08個，不考慮上下文切換的話，約等於5個執行緒。同時還要考慮cpu的核心數和利用率問題，那麼我們得到了最佳執行緒數計算的公式：
(（cpu time + cpu wait time）/ cpu time) * coresize * cupratio
得到了最大的執行緒數和qps的計算方式：
qps = thread num * 單執行緒qps = （cpu time + cpu wait time）/cpu time * coresize * cupratio * (1000ms/(cpu time + cpu wait time)) = (1000ms/ cpu time) * coresize * cpuratio
所以決定乙個系統最大的qps的因素是cpu time、coresize和cpu利用率。看似增加cpu核數（或者說執行緒數）可以成倍的增加系統qps，但實際上增加執行緒數的同時也增加了很大的系統負荷，更多的上下文切換，qps和最大的qps是有偏差的。
cpu time就是一次請求中，實際用到計算資源。cpu time的消耗是全流程的，涉及到請求到應用伺服器，再從應用伺服器返回的全過程。實際上這取決於你的計算的複雜度。
cpu wait time是一次請求過程中對於io的操作，cpu這段時間可以理解為空閒的，那麼此時要盡量利用這些空閒時間，也就是增加執行緒數。
cpu 利用率是業務系統利用到cpu的比率，因為往往乙個系統上會有一些其他的執行緒，這些執行緒會和cpu競爭計算資源，那麼此時留給業務的計算資源比例就會下降，典型的像，gc執行緒的gc過程、鎖的競爭過程都是消耗cpu的過程。甚至一些io的瓶頸，也會導致cpu利用率下降(cpu都在wait io，利用率當然不高)。
從上面的公式我們可以看出，假設cpu time和cpu 利用率不變，增加cpu的核數能使qps呈線性增長。但是很遺憾，現實中不是這樣的…首先先看一下阿姆達爾定律：
阿姆達爾定律給出了任務在固定負載的情況下，隨著系統資源的提公升，執行速度的理論上限。以計算機科學家gene amdahl命名。
其中slatency: 整個任務的提速比。
s: 部分任務得益於系統資源公升級帶來的提速比。
p: 這部分任務執行時間佔整個任務執行時間的百分比（系統資源提公升前）。
從上可以得到：
以上公式說明了通過資源公升級來給任務加速的加速比上限，而且和提速的幅度無關，理論加速比總是受限於不能加速的任務的比例。
阿姆達爾的定律常用於平行計算中，用來估計多處理器情況下的理論加速比。例如，如果有個程式在單核下需要執行20個小時，並且不能被並行處理的部分佔1個小時的執行時間，剩餘的19個小時(p=0,95)的任務可以並行化，那麼不管有多少核心來並行處理這個程式，最小執行時間不可能小於乙個小時。由此得到，理論加速比的上限是20倍（1/(1-p) = 20）。因此，平行計算只和少數的核心和極度可並行化的程式相關。
同樣，對於1000ms/(cpu time) * coresize * cpuratio我們不斷的增加coresize或者說執行緒數的時候。我們的請求變多了，隨之而來的就是大量的上下文切換、大量的gc、大量的鎖徵用，這些會增加不可並行部分的總時間，也會大大的增加cpu time。假設我們的序列部分不變的話，增大核數，cpu不能得到充分的利用，利用率也會降低。所以，對於阿姆達爾定律而言，不可並行部分的比率才是決定著是否能成倍增長效率的關鍵。也就是說最佳執行緒數也好，最大qps也好，增加核心數量不一定能是系統指標有成倍的增長。更關鍵的是能改變自己的架構，減小序列的比率，讓cpu更充分的利用，達到資源的最大利用率。
通過上面一些例子，我們發現當執行緒數增加的時候，執行緒的上下文切換會增加，gc time會增加。這也就導致cpu time 增加，qps減小，rt也會隨著增大。這顯然不是我們希望的，我們希望的是在核數一定的情況下找到某個點，使系統的qps最大，rt相對較小。所以我們需要不斷的壓測，調整執行緒池，找到這個qps的峰值，並且使cpu的利用率達到100%,這樣才是系統的最大qps和最佳執行緒數。
深入淺出QPS RT和最佳執行緒數
qps是每秒鐘處理完請求的次數。這裡的請求不是指乙個查詢或者資料庫查詢，是包括乙個業務邏輯的整個流程，也就是說每秒鐘響應的請求次數。響應時間即rt，處理一次請求所需要的平均處理時間。對於rt，客戶端和服務端是大不相同的，因為請求從客戶端到服務端，需要經過廣域網，所以客戶端rt往往遠大於服務端rt，同...
qps是什麼意思 深入淺出QPS RT和最佳執行緒數
什麼是qps qps是每秒鐘處理完請求的次數。這裡的請求不是指乙個查詢或者資料庫查詢，是包括乙個業務邏輯的整個流程，也就是說每秒鐘響應的請求次數。響應時間即rt，處理一次請求所需要的平均處理時間。對於rt，客戶端和服務端是大不相同的，因為請求從客戶端到服務端，需要經過廣域網，所以客戶端rt往往遠大於...
深入淺出sizeof
int佔 位元組,short佔 位元組 1.0 回答下列問題 答案在文章末尾 1.sizeof char 2.sizeof a 3.sizeof a 4.strlen a 如果你答對了全部四道題，那麼你可以不用細看下面關於sizeof的論述。如果你答錯了部分題目，那麼就跟著我來一起 關於sizeof...