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

摘要:我提倡使用最小化資源的方式做一次壓力測試，排除大部分淺顯的應用問題。最小資源的意思，即在pc環境，使用應用可以運行的最小資源狀態下，進行壓力測試和性能問題偵測的工作?！　∏懊婵吹接腥酥vj2ee的性能調優，雖然這塊不是自己的專長，但是豬養多了，也忍不住跳出來說幾句。

　　雖然幾乎每本講性能調優的書籍開篇都會提，沒必要的情況下就不要做調優，但是我個人還是認為，所有系統在上線前，都應該做一次基本的壓力測試并對相關的性能問題進行檢測， 但是迫于資源壓力，很多項目都無法做正規的壓力測試，一直到系統上線出現問題，才倒回來找原因。 而正規的壓力測試，往往因為需要嚴格模擬生產環境，需要耗費大量的資源，各類專家配合解決問題，并不是那么輕松的可以做下來的。

　　而j2ee應用的特點就是以復雜性來回避傳統問題，所以任意一個j2ee的部署，相對于php那樣的結構都是比較復雜的。系統一旦發生性能問題，必須在程序、數據庫、應用服務器、jvm、操作系統幾大塊中交叉進行考慮，根據實際情況問題，問題的原因可能異常復雜。我們可以想象一個項目，從來不做UT不做IT ，只做一次UAT，然后直接提交給用戶上線以后，修補錯誤的困難度和成本。

　　經?？吹揭恍┱{優的最后解決方案，可以肯定，幾乎80%以上都是一些低級的程序錯誤導致的，剩下的20%雖然可能是用硬件，os參數調整等等問題解決了，但是其中很大一塊，歸根到底也是程序的問題。 而在我們回顧這些錯誤的時候可以很驚人的發現，大部分都是一些低級錯誤。

　　我提倡使用最小化資源的方式做一次壓力測試，排除大部分淺顯的應用問題。最小資源的意思，即在pc環境，使用應用可以運行的最小資源狀態下，進行壓力測試和性能問題偵測的工作。這種做法的優點如下。
　　1. 環境容易搭建， 特別是不需要考慮大型硬件和網絡條件等等，也回避了開發人員可能不熟悉unix和特定應用服務器等問題
　　2. 不需要特別的數據庫，操作系統和應用服務器專家配合，開發人員自身即可完成。
　　3. 不需要特別的依賴os和應用服務器，jvm的監測工具。選擇自己最熟悉的即可。
　　4. 開發人員在熟悉這種過程以后，再轉到正式的生產環境工作時也更有經驗，更容易解決問題。

　　對測試過程做一點簡單介紹。

　　工具準備：

　　得益于開源技術的發展，大部分工具都可以免費獲得，使用也比較簡單。
　　1. jvm 監控： 對jvm的運行狀態進行分析， 可以使用jvm自身帶的特性輸出日志，結合hp的jmeter profile進行分析。也可以使用jrockit自帶的圖形化工具mession control。
熟悉什么用什么，越簡單越好，目的主要是觀察內存堆的變化，線程資源變化，gc情況等。
　　2. 數據庫監控工具： 熟悉數據庫的使用數據庫自身的特性，不熟悉的可以使用第三方工具，主要目的是觀察數據庫的鎖，連接數信息， 對于db2我比較喜歡使用quest central。 oracle使用OEM或者自身的數據字典已經可以。
　　3. 應用服務器監控： 主要目的是記錄方法的調用情況和執行時間 ，找出頻繁調用的方法和執行時間過長的方法。使用jprobe和jprofile都可以很輕松的做到。 如果使用的應用服務器比較偏門，那么可以換一個支持這種檢測工具的應用服務器。反正主要目的只是在找問題。
　　4.  sql執行監控：跟蹤找出執行時間過長的sql。 我喜歡使用p6spy。
　　5. 壓力工具： jmeter+badboy , 有條件的可以用loadrunner， 和loadrunner近似的還有一個免費的開源產品。 另外web 應用的話， 也可以使用selenium這樣的ff擴展來做。微軟vs自帶的也不錯，反正是什么簡單用什么。
　　6. 記錄表格： 對問題和資源配置的變更進行記錄和對比。

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

    設置：
　　1. 數據庫： 如果未使用連接池， 則盡可能的將數據庫允許連接設置成最小數字，推薦是從1開始。如果使用連接池，則設置為1.
隨著并發模擬數的增加也可以適當上調，但是一定要低于壓力工具模擬的并發用戶數。數據庫環境盡可能接近生產環境，至少要有足夠的測試數據。
　　2. 應用服務器： 對jvm啟動堆做最小化設置。比應用服務器要求的最低內存略高，保證應用可以正常啟動即可。根據模擬用戶數增加可以小步適當上調，但是以保證應用基本運行即可。千萬別來大內存。

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