壓力測試和系統優化tips

    昨天有個朋友問題對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.疊代平衡瓶頸。