平常的工作中，在衡量伺服器的效能時，經常會涉及到幾個指標，load、cpu、mem、qps、rt，其中load、cpu、mem來衡量機器效能，qps、rt來衡量應用效能。
一般情況下對於機器效能，load、cpu、mem是越低越好，如果有乙個超過了既定指標都代表著可能出現了問題，就需要盡快解決（當然有可能是應用的問題也有可能是機器上其他程式引起的），反正就是如果不解決，時間長了肯定不好。
而對於應用效能的兩個指標，qps當然是希望越大越好，rt越小越好。提高qps可以充分利用機器資源，更少的機器來完成更多的請求，而降低rt會提公升響應速度，提公升使用者體驗。
平時做效能優化或者查詢效能問題的目的，就是在提高qps，降低rt、保證load、cpu、mem穩定，但是至於他們之間有什麼關係，是否有相互影響，各個指標主要由那些因素決定等等，往往是兩眼一抹黑。優化點做了就是做了，至於會有什麼結果，為什麼會生效，會不會對其他指標有什麼影響，心裡多少是沒有底的，先上線看看再說，不行再來。
本文的目的是梳理下日常工作中涉及到效能點時的一些思考，總結方法和理論，形成自己的方**，希望對以後類似的工作有一定的指導。
在進行理論總結之前，對接下來要用到的一些引數做下說明：
qps：一秒鐘內完成的請求數量
rt： 乙個請求完成的時間
tic： 執行緒的cpu計算時間
tiw：執行緒的等待時間（io/網路/鎖）
tn： 執行緒數
tno：最佳執行緒數
cn：cpu核數
cu：cpu使用率
注：以下的討論均限於機器負載小於平均負載的情況，機器負載太高的時候，以下的公式並不適用。
rt的計算公式：
qps計算：
對於rt和qps的計算公式大家都已經很熟悉，不做過多說明，在這裡引出乙個重要的概念，最佳執行緒數。
最佳執行緒數的定義：剛好消耗完伺服器瓶頸資源的臨界執行緒數。計算公式如下：
如何理解最佳執行緒數和其計算公式？
在一般的伺服器上，程式執行的瓶頸資源有可能是cpu、也可以是記憶體、鎖、io等，他們都可以影響到程式執行的時間，體現在公式上就是tic和tiw，分表代表程式執行的cpu執行時間和程式等待資源的時間。因此理論上，為了讓cpu充分使用，執行程式的執行緒數就是（tic + tiw）/tic。
這裡說下我對tic和tiw的理解，既然瓶頸資源不僅僅只是有cpu，為什麼要把cpu單獨拎出來，而其他種種都歸結為tiw。我想是因為機器的效能受影響的因素很多，不可能全部體現在公式中，為了方便計算和推理，所以選擇了好統計的tic做為乙個主要指標，而其他都歸結為tiw。所以這只是乙個計算上的技巧，公式不代表真實情況，但是公式可以給我們指明方向，簡化思考的方法。
目前線上機器都是多核的，那麼在多核情況下，應用qps的計算應該是：
cu是cpu使用率，線上機器一般不會把cpu跑到100%，所以在計算qps時需要乘上乙個係數，代表期望cpu使用率使用情況下的qps。
一般寫**的時候還會用到多執行緒，那麼多核多執行緒下qps為：
多核最佳執行緒下qps：
可以看到在最佳執行緒下，qps的大小只和tc成反比，也就是說要增大qps只要減小tic就可以了。
但是最佳執行緒數的計算公式中可以看出，應用的最佳執行緒數是和實際的運**況相關的，是乙個隨時變化的量，在應用執行過程中很難確定乙個明確的值，所以qps的計算公式還需要根據實際情況來做下改變。最終qps計算如下，tn一般是乙個確定的值，即處理邏輯執行緒池的大小，而tno是乙個理論計算值。
現在讓我們用例子在測試驗證下。
壓測模型如下：
對於我們大多數系統來說，業務邏輯都不是很複雜，需要耗費大量cpu計算的場景很少，因此
tic在rt中的佔比不是很高，佔比高的還是tiw。
壓測結果如下：
結論：在之前的測試中，有乙個既定條件，即執行緒的大小被預設為最佳執行緒數，但是線上機器執行過程中，最佳執行緒數是很難計算的，處理邏輯的執行緒池大小也不可能剛剛好就是最佳執行緒數，往往不是大了就是小了，只能接近於最佳執行緒數。
執行緒數過小的結果，qps上不去，cpu利用率不高，rt不變，這個很好理解，極端情況下只有乙個執行緒，那麼tiw這段時間內，cpu其實是白白浪費了。
執行緒數過大（超過最佳執行緒數），我們先把結論擺出來，再來求證。
之前寫到rt的計算方法是，rt=tic+tiw，但是這是單執行緒或者最佳執行緒情況下的，非最佳執行緒情況下，rt的計算公式應該如下：
即：rt = （併發執行緒數/最佳執行緒數）* 最佳執行緒時的rt。
我們對上面的公式進行下處理，可以得到：
為什麼呢，因為實際執行過程中，實際的最佳執行緒數的大小是不會超過設定的執行緒大小的，所以在tn當執行緒的數量超過最佳執行緒數之後，rt的則和執行緒數正相關，即執行緒越多rt越長，這其實也是很好理解的，執行緒的rt由tic和tiw構成，一般情況下tic不會有太大的變化，rt變成說明執行緒等待的時間變長，超過最佳執行緒之後，說明執行緒增加了一部分等待時間，有可能是在等待鎖（鎖的競爭更激烈）、或者是在等待cpu排程、或者是執行緒切換太高。
一圖來總結下執行緒數、qps、rt之間的關係：
在平時的應用效能優化過程中：
接下來讓我們來看看衡量機器效能的指標——load 和 cpu使用率。
cpu使用率：程式在執行期間實時使用的cpu比率。
load：代表著一段時間內正在使用和等待使用cpu的任務平均數，這是乙個很玄妙的定義，我至今沒有完全明白它的確切的定義和計算公式。
鑑於load的計算沒有明確的計算公式，因此不好分析影響load的因素，也不好像應用效能那樣總結出影響qps和rt的具體原因，現在只對load表現出來的問題做一些總結。
即機器的load很高，但是應用的qps、rt都不高，這種情況可能有以下幾種原因：
檢視機器load高的常見方法：
即機器load很高，應用qps也很高：
對於load偏高的原因，不僅僅只是有應用自身引起的，機器上其他程式也有可能導致機器整體的load偏高。
影響系統效能的具體因素還有很多，如記憶體就是很常見的問題，記憶體洩露、頻繁gc等，因此記憶體也應該被重視，限於篇幅，記憶體的問題不專門展開。
影響系統效能的因素有很多，沒有乙個明確的公式或者方法能說明是哪乙個具體的因素對系統造成了多大的影響，對其他相關因素又產生了多大的影響，影響是好是壞。
正是因為這種複雜性和不確定性給系統效能優化和查詢效能問題帶來了困難，實際工作中還是要針對具體問題具體對待，但是我們可以對已知的問題和方法做歸納和總結，並逐步在實際問題中去驗證和豐富擴充，以形成解決問題的方**。
關於 伺服器開發的一些思考 16 01 31
最近在閱讀一些開源專案，從中學習優秀的設計理念，並且與以往自己做過的專案 經驗進行對照，以求將優秀的設計理念融入進實際的開發之中。雖然這在很大程度上是屬於重複造輪子的行動，但是，沒錯，這就是在重複造輪子，而且我也喜歡重複造輪子，從大二重新實現了struts2的時候，就開始了造輪子之路。對業務開發的厭...
Linux伺服器程式效能測試的一些思考
工作中對專案壓力測試的一些心得，先自我作乙個小結吧！一 巨集觀與微觀相結合 1 巨集觀層面 即系統的一些關鍵效能指標，如 各程序所佔cpu的百分比 記憶體消耗 網路包量 磁碟io等等，詳細指標列舉如下 名稱 描述 參考值 cpu useage cpu 的使用時間百分比。平均值小於70 p roces...
對提高HBase寫效能的一些思考
以下為使用hbase一段時間的三個思考，由於在記憶體充足的情況下hbase能提供比較滿意的讀效能，因此寫效能是思考的重點。希望讀者提出不同意見討論 1 autoflush false的影響 2 hbase.hregion.max.filesize應該設定多少合適 hbase中hfile的預設最大值 ...