性能測試調(diào)優(yōu)一：
1.首先，看下選測交易的整個走向
純系統(tǒng)內(nèi)部交易：
選測交易如果是系統(tǒng)內(nèi)的交易，每一步請求都和系統(tǒng)交互幾次，訪問了幾個數(shù)據(jù)庫，訪問了數(shù)據(jù)庫的那幾張表？？
該交易走了那幾臺機(jī)器，這幾臺機(jī)器的網(wǎng)絡(luò)連接情況是什么樣的？？這幾臺機(jī)器是通過走的是哪些虛擬網(wǎng)卡，走了哪些路由器？？帶寬是什么情況？？
該交易在這幾臺機(jī)器上消耗了多少CPU，內(nèi)存，及其對磁盤做了多少次的訪問？？
從方法層面，從該交易的發(fā)起到結(jié)束，起了多少線程，調(diào)用了哪些相關(guān)的方法以及接口，訪問了哪些表？？？
跨系統(tǒng)交易：
該交易發(fā)起后，每一步請求在系統(tǒng)內(nèi)走了幾次，調(diào)用了哪些接口，調(diào)用了幾次，訪問了哪些數(shù)據(jù)庫以及哪幾張表？？

了解了以上內(nèi)容后，才能準(zhǔn)確的把握每個交易的壓力點(diǎn)在哪里

在性能瓶頸分析時，從不同的層次去分析問題可能出現(xiàn)在哪一個具體的位置

2.合理的利用各種監(jiān)控工具

系統(tǒng)資源監(jiān)控，通常通過nmon來監(jiān)控分析

應(yīng)用層的監(jiān)控，通常通過開源的工具如jprofile? java自帶的jconsole visualvm以及商業(yè)化的軟件如dynatrace

數(shù)據(jù)庫層的監(jiān)控，通常利用數(shù)據(jù)庫本身的DB Snapshot（DB2快照? DB2top? ? Oracle的AWR報告） 或者 Spotlight on? db2? ?oracle 等等

3.仔細(xì)檢查系統(tǒng)的各項參數(shù)配置，確保這些參數(shù)在最優(yōu)狀態(tài)

應(yīng)用線程池

應(yīng)用的日志級別

數(shù)據(jù)庫連接池

操作系統(tǒng)級別的參數(shù)：文件句柄、TCP連接數(shù)等等

各個機(jī)器的資源大小是否合理：cpu、內(nèi)存、磁盤空間、網(wǎng)絡(luò)情況等

某些特定應(yīng)用自帶的一些參數(shù)設(shè)置（ESB? 大數(shù)據(jù)平臺等）

發(fā)壓端的機(jī)器配置（網(wǎng)路情況、CPU、內(nèi)存等等）

發(fā)壓腳本的參數(shù)化以及參數(shù)化取值的方式是否合理，發(fā)壓腳本是否本身存在一些bug或者不合理的內(nèi)容

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

直到找到最終的問題所在

幾種常見的問題分析：

??　　　壓力上不去，不管怎么增加用戶，系統(tǒng)的壓力始終維持在一個點(diǎn)，且此時的資源消耗也很少，幾乎可以忽略不記

查看系統(tǒng)日志，看是否有相關(guān)報錯信息，如應(yīng)用線程不足、數(shù)據(jù)庫連接不足的情況，如果存在，調(diào)整后驗(yàn)證問題是否還存在

通常該情況是在某個資源的限制導(dǎo)致了壓力傳導(dǎo)不了后方，當(dāng)然上述只是個人遇到的情況，也可能是其他原因造成的，需要根據(jù)實(shí)際

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

以下幾種在后續(xù)在分析：

　　　隨著壓力的上升，響應(yīng)時間變長

　　　隨著壓力的上升，TPS出現(xiàn)波動

　　　并發(fā)過程中，大量報錯，交易成功率過低

　　　等等。-------未完待續(xù)

本人技術(shù)能力有限，還希望看到本文的大師多多指教，相互學(xué)習(xí)，共同提高

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 2018年8月

?

轉(zhuǎn)載于:https://www.cnblogs.com/vinnfung/p/9465401.html

總結(jié)

以上是生活随笔為你收集整理的性能测试调优篇---未完待续的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。