摘要:我提倡使用最小化資源的方式做一次壓力測試，排除大部分淺顯的應用問題。最小資源的意思，即在pc環境，使用應用可以運行的最小資源狀態下，進行壓力測試和性能問題偵測的工作。

　　前面看到有人講j2ee的性能調優，雖然這塊不是自己的專長，但是豬養多了，也忍不住跳出來說幾句。

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

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

　　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。