j2ee性能調優之最小化資源壓力測試法則[2]

　　j2ee性能調優之最小化資源壓力測試法則[2]   軟件測試　

   　我發現有些人做壓力測試，只用壓力工具來跑，不肯用各類proile工具來跟蹤應用和數據庫使用情況，加上經驗又不足，結果測來測去都是瞎猜。

　　設置：

　　1. 數據庫： 如果未使用連接池， 則盡可能的將數據庫允許連接設置成最小數字，推薦是從1開始。如果使用連接池，則設置為1.

　　隨著并發模擬數的增加也可以適當上調，但是一定要低于壓力工具模擬的并發用戶數。數據庫環境盡可能接近生產環境，至少要有足夠的測試數據。

　　2. 應用服務器： 對jvm啟動堆做最小化設置。比應用服務器要求的最低內存略高，保證應用可以正常啟動即可。根據模擬用戶數增加可以小步適當上調，但是以保證應用基本運行即可。千萬別來大內存。

　　3. 壓力模擬并發數，從1開始逐步往上加。一次加1，2個，上限不要太高，5-10個足以。

　　步驟

　　1. 按1用戶1連接的方式進行檢測

　　* 找出系統是否存在明顯的資源泄露，比如數據庫連接，如果存在泄露此種情況下服務器很容易就hold。

　　* 找出執行時間過長的java方法和sql。進行分析修改。

　　* 找出那些調用過多的方法和sql，對程序進行分析，看是否做了不必要的調用。 這個問題尤其在使用了第三方包的情況下要小心，我曾經監測出某人寫的東西一個方法間接的調用了數據庫操作近200次。

　　有些人做測試喜歡從5以上的數字開始，實在不是什么好習慣，比較明顯的問題都容易回避了。

　　2. 適當增加并發用戶，盡可能不調整應用內存，對系統進行長時間的壓力測試，比如2-4個小時。 重點觀察是否存在內存泄露問題。 內存泄露的問題比較復雜，有時候還依賴于jvm和os，另外有些內存泄露只能在大并發的多線程環境下才會出現。 但是這種測試可以排除掉一些明顯的問題，主要是緩存和隊列之類的東西。內存泄露一般jvm會有報錯和相關的日志dump文件。

　　3. 逐步增加并發用戶和連接數，觀察是否存在sql鎖 和線程鎖的問題。另外并發情況下也可能存在其他一些資源沖突，比如讀寫文件的情況等等。

　　線程情況可以使用監控工具觀察，比如jrockit帶的mc， 也可以直接dump jvm 內存快照找工具分析。

　　4. 盡可能增加并發用戶數，以當前應用能承擔的上線進行長時間測試，比如半天到1天，觀察是否會存在內存泄露，是否會存在線程資源消耗的問題。也需要檢查一下數據庫的連接數情況，看是否會一直持續增加，這說明連接池實現有問題，或者設置過大，也可能是jdbc的問題。

　　5. 其他： 對jvm 可以使用sun和bea的都對比跑一下， 兩個實現情況大不同。 jr大并發支持好，所以可能jr上沒問題，但是sun的就有問題了。

　　大部分的問題應該都可以在步驟1，2能得到暴露。在完成了這樣的初步測試以后，正式的測試就省心不少了，如果客戶有錢，性能不好也可以直接更新硬件了，省事又創造GDP。

原文轉自：http://www.anti-gravitydesign.com