昨天有個朋友問題對mina是否有什麼優化的資料，他這邊一個系統壓到500併發就上不去了，開始在看中國好聲音，也沒多想，直接說我這邊沒有。後來中間休息的時候，發現回答的有點問題，心裡覺得其實應該告訴他壓測的tips，找到瓶頸才能知道問題所在，昨晚初略的說了一下，今天把以前的一些經歷回憶一下，貼出來，多少對一些新人有幫助。     這裡主要還是說一下經驗，具體的工具不太多的說了，以前寫的一些blog多少有提到。首先判斷壓測需要開始查問題的情況是加併發使用者，TPS不增長了，甚至開始下跌了，RT不動了，甚至開始上漲了。（這兩者有時候是有關聯變化的，有時候是沒有關聯的變化的）     然後開始分析問題，第一件要做的事情：判斷自己用的壓測方式和工具（lr，ab，自己寫的多執行緒客戶端）是否正確，有好幾次都是找了一圈發現測試端出現了問題（這是很悲催的），這類問題如何定位？找恆定基準（空掛web容器，mock物件固化RT）。     第二件事情，用作業系統的資源監測命令（linux 命令翻出來看看），cpu利用率，load，memory使用情況（cache，swap，應用佔用），上下文切換情況，io wait，網路資料量，資料包丟包情況，檔案控制代碼配置等等。根據這些指標判斷，在使用者併發增加的時候，哪些指標變化的厲害，甚至已經明顯成為瓶頸。如果你是java應用，那麼多看看jvm的gc，執行緒dump出來看看是否有大量lock，或者有單執行緒吃掉固定的cpu等等。     第三件事情，開始定位到底什麼引起了這些基礎資源成為瓶頸。首先先要排除依賴系統的問題，所謂依賴系統，比如web容器，集中式快取，db等等，這些系統通常你沒有辦法debug，最重要的是去看看他們的log，對於warning，error特別注意，例如nginx對於資料包上下行會有配置，到一定大小就開始藉助磁碟來緩解記憶體壓力，不留意壓力就上不去了，同時io也會很多。接著開始拆解你應用的各個模組，mock的方法來保證無消耗介面依賴，這樣再反覆測試定位問題。大志定位到某一個模組有影響的時候，一定要注意，這只是嫌疑犯，如果你寫過有指標的語言你就會理解，往往問題發生在非爆發點。同時要提醒一點的是，很多時候當你真實的判斷出一個瓶頸點的時候，優化了它，也許效能更低，為啥，例如A和B兩個模組，A是瓶頸tps為30,B的tps是35,此時你把A優化到了tps為50,但是對於B來說壓力明顯就增大了，此時B可能由於資源壓力tps開始下降（就是前面提到的併發使用者上升除了保持平線，還可能下降）。    可能說到這裡很多人覺得這都是常識，也沒啥實質內容，其實首先就是找問題，然後就是用你語言熟悉度和業務設計來破隙問題。最後說最常用的幾個所謂的優化萬精油：    1.減少關鍵業務路徑的RT總和。很多時候糾結與所謂的程式碼級別省，不如業務直接優化一點來的天崩地裂。（基礎系統除外）    2.瓶頸資源，例如第二步說的所有指標資源和依賴系統的資源（例如web容器的執行緒數等）等。對瓶頸資源做兩種處理：a.高效使用。（例如db的批量處理，快取的批量獲取，磁碟的批量刷出）b.少用。對資料一致性要求不高的情況下可以做一些本地快取等等。c.快速釋放。寫過事件驅動程式碼的同學應該深有體會，將業務處理切割細化以後，原本hold的資源也會被碎片化的使用。（其實我們學習計算機cpu演進的時候就能看到這通俗的道理），快速釋放意味著同樣資源可以服務更多請求者。d.交換資源。磁碟換記憶體，多核cpu處理能力換儲存。有興趣可以看看TOP已經用了兩年多的流式計算框架裡面的設計細節。    3.換依賴，包括web容器，集中式快取，磁碟等等，換他們並不一定是他們不好，而是也許資料結構不支援導致需要多次操作（集中式快取），多系統間有更好的私有互動協議（反向代理和web容器之間），本身被革命了（固態硬碟）。   先寫到這裡，多少應該有點幫助，或者你遇到類似問題會有點共鳴，如果你是做業務系統，那麼這個萬精油的順序就是你最好的改進順序。   還是那句話，優化這東西就四步：1.找。2.定位。3.分析。4.迭代平衡瓶頸。