性能測試調優篇---未完待續

性能測試調優一：
1.首先，看下選測交易的整個走向
純系統內部交易：
選測交易若是是系統內的交易，每一步請求都和系統交互幾回，訪問了幾個數據庫，訪問了數據庫的那幾張表？？
該交易走了那幾臺機器，這幾臺機器的網絡鏈接狀況是什麼樣的？？這幾臺機器是經過走的是哪些虛擬網卡，走了哪些路由器？？帶寬是什麼狀況？？
該交易在這幾臺機器上消耗了多少CPU，內存，及其對磁盤作了多少次的訪問？？
從方法層面，從該交易的發起到結束，起了多少線程，調用了哪些相關的方法以及接口，訪問了哪些表？？？
跨系統交易：
該交易發起後，每一步請求在系統內走了幾回，調用了哪些接口，調用了幾回，訪問了哪些數據庫以及哪幾張表？？

瞭解了以上內容後，才能準確的把握每一個交易的壓力點在哪裏

在性能瓶頸分析時，從不一樣的層次去分析問題可能出如今哪個具體的位置

2.合理的利用各類監控工具

系統資源監控，一般經過nmon來監控分析

應用層的監控，一般經過開源的工具如jprofile  java自帶的jconsole visualvm以及商業化的軟件如dynatrace

數據庫層的監控，一般利用數據庫自己的DB Snapshot（DB2快照  DB2top    Oracle的AWR報告） 或者 Spotlight on  db2   oracle 等等

3.仔細檢查系統的各項參數配置，確保這些參數在最優狀態

應用線程池

應用的日誌級別

數據庫鏈接池

操做系統級別的參數：文件句柄、TCP鏈接數等等

各個機器的資源大小是否合理：cpu、內存、磁盤空間、網絡狀況等

某些特定應用自帶的一些參數設置（ESB  大數據平臺等）

發壓端的機器配置（網路狀況、CPU、內存等等）

發壓腳本的參數化以及參數化取值的方式是否合理，發壓腳本是否自己存在一些bug或者不合理的內容

4.根據遇到的具體問題發揮你聰明的大腦，逐層分析，驗證性能瓶頸的懷疑對象，逐個排除

直到找到最終的問題所在

幾種常見的問題分析：

  　　　壓力上不去，無論怎麼增長用戶，系統的壓力始終維持在一個點，且此時的資源消耗也不多，幾乎能夠忽略不記

查看系統日誌，看是否有相關報錯信息，如應用線程不足、數據庫鏈接不足的狀況，若是存在，調整後驗證問題是否還存在

一般該狀況是在某個資源的限制致使了壓力傳導不了後方，固然上述只是我的遇到的狀況，也多是其餘緣由形成的，須要根據實際

的狀況去具體問題具體分析。

如下幾種在後續在分析：

　　　隨着壓力的上升，響應時間變長

　　　隨着壓力的上升，TPS出現波動

　　　併發過程當中，大量報錯，交易成功率太低

　　　等等。-------未完待續

本人技術能力有限，還但願看到本文的大師多多指教，相互學習，共同提升

                                                                              2018年8月