作者：Steven Haines；編譯：仙人掌工作室
前面一篇文章指出了性能優化的目的是提高應用支持的並發用戶數量以及吞吐量、可靠性，優化的手段則應當是從應用、應用服務器、平台、外部依賴因素入手作系統地調整。無論是優化J2EE（J2EE培訓 ）應用還是數據庫、自定義的體系結構，最好的方法是先確定要采用的優化策略、分析該策略是否能夠解決性能問題、確定實施該策略所需滿足的前提條件。
一、優化方法
雖然我也希望能夠告訴你：優化J2EE環境很簡單，只需要把某幾個參數調整到特定的值，一個小小的表格就足以把這些值全部列出。遺憾的是，實際問題要復雜得多，優化J2EE性能不僅要深入理解應用本身，而且還要掌握用戶使用該應用的方式。下圖展示了完整的優化過程。
圖2-1：調整性能因素的方法概覽
第一個必須考慮的因素就是用戶，我們必須先回答下列問題：用戶會怎樣使用這個系統？根據問題的答案可以定義出一組要求系統執行的事務（在這裡，“事務”這個概念是指用戶發出的一系列請求）。注意這些事務必須能夠典型地代表最終用戶的操作行為，因為我們將根據這些事務的執行情況來調整系統！
接下來，我們要在負載測試工具之內生成這些事務。負載測試工具能夠控制並發用戶數量、考慮時間、啟動延遲等因素。
模擬大量用戶的操作方式對應用進行測試時，應當獲取應用本身、應用服務器、底層平台、外部資源的運行時性能指數。最後，有了這些性能指數之後，還必須對這些數據進行對比、分析和解釋。
二、應用
每一個應用都是不同的：響應用戶請求的服務步驟不同，與後端資源的交互方式不同，業務需求也不同。例如，考慮一個合作伙伴通過Internet發送和處理交易請求的應用，其核心事務顯然應該是收取交易請求，將交易請求提交給數據庫，最後返回回執。相比之下，電子商務Web網站的核心事務就不同了，它的核心事務應該是提供一個可購買產品的目錄，維護購物籃，以及處理購買信息。
既然所有應用都是不同的，那麼它們使用應用服務器資源的方式也不同，必須針對應用的具體情況指定不同的應用服務器配置。優化性能過程中最為重要的一個步驟就是：深入理解業務需求，定義一組精確反映最終用戶操作方式的典型事務。如果這一步沒有做好，很難指望應用會在實際運行環境中有好的表現。
三、負載測試
負載測試工具是一種能夠模擬任意數量的用戶與系統交互過程的工具，當前市場上已經有許多這類工具（參見本文後面的目錄），雖然這些產品各有特色，但它們的核心功能不外乎：
◆ 能夠針對應用系統執行用戶定義的事務，保證適當的事務頻度。
◆能夠控制負載測試中並發用戶的數量。
◆能夠精確調整測試器在下列各方面的行為：兩個請求之間用戶的思考時間，上升到目標用戶數量的速率。
大多數商業負載測試器還提供了一個“學習”引擎，它允許測試者手工執行事務，而學習引擎則在後台觀察和記錄測試者的動作。
總之，負載測試工具的目的是模擬實際運行環境中用戶的操作方式。如果不能為應用定義一組典型的測試事務，就不能將應用精確地調整到最適合實際用戶的狀態。
四、需要哪些信息？
現在，我們已經有了模擬一系列並發用戶的負載測試工具，每一個並發用戶都能夠運行典型地代表了應用使用情況的事務。接下來要做的是從應用和應用服務器獲取運行時性能信息，包括：
◆應用服務器統計信息：內存使用情況，數據庫連接使用情況，線程使用情況，等等。
◆應用性能（內部）：類和方法的響應時間，調用路徑，異常方法，等等。
◆應用性能（外部）：負載測試器觀察到的事務總量、構成事務的請求量。
◆平台性能：CPU，進程，等等。
◆後端資源性能：數據庫性能，傳統系統性能，等等。
五、如何獲取這些信息？
我們主要探討如何獲取應用和應用服務器的性能數據；硬件、後端資源的性能數據已經超出了本文的范圍。不同的應用服務器以不同的方式提供運行時性能數據，為了統一獲取性能數據的機制，Sun發布了Java管理擴展（JMX，即Java Management Extension）。雖然目前JMX還未被所有的應用服務器廠商采用，但BEA WebLogic、IBM WebSphere 5、JBoss都已經選擇JMX作為管理API，並通過JMX導出其配置和運行時信息；其他的應用服務器廠商也都提供了各自私有的獲取運行時信息的辦法，或者是通過提供幾個專用的Servlet，或者是通過命令行工具。
相比之下，獲取應用的性能數據就比較復雜一些。雖然一些應用服務器能夠監視應用的性能，報告最基本的性能信息，但一般而言，獲取應用性能數據首選的辦法還是通過代碼指令。代碼指令既可以直接嵌入到應用體系之內，例如在應用中嵌入一些監視性能的代碼，然後通過某種方式導出到外部；或者也可以利用一個獨立的進程，由該進程監視應用代碼的運行情況。
有許多商業軟件廠商已經實現了能夠連接到應用服務器的類裝入器的代碼指令，這樣我們就不必對應用本身大動干戈，只要把應用部署到安裝了監視設施的應用服務器上，應用服務器就會自動在創建應用的類時開始監視。
在代碼監視期間到底要收集哪些信息通常是可配置的，小到僅僅記錄某個特定方法的響應時間，大到記錄每一個發送給應用服務器的事務。不同的監視要求帶來對系統的不同的開銷和影響，收集的數據越多，監視操作的開銷就越大，反之亦然。
六、比較和分析數據
前面我們探討了如何在應用系統上用模擬負載進行測試，以及如何獲取應用和應用服務器的運行時性能數據，接下來要做的就是比較和分析獲得的數據，搞清楚每一個數據指標對系統性能的影響。如果要簡略一點，這些數據可以用簡單的折線圖來表示，每次顯示出一組或者多組數據，但大多數商業軟件都提供了很強大的表現能力——包括用圖形的方式來描述樹形的調用路徑，有的還有縮放功能。一些商業軟件還能夠顯示出對比不同指標的運行時數據視圖，有時可以當作指示性能問題的專用指示器。
結束語：在考慮優化性能的方法時，通常下列三個步驟是必不可少的：第一，用典型的最終用戶事務，對應用進行負載測試；第二，從應用服務器和應用獲得運行時性能數據；第三，分析性能數據，在此基礎上調整相關的性能選項。
優化J2EE環境是一個需要反復進行的過程：第一次只能從一個看起來似乎不錯的配置開始，然後測試、分析系統，再根據測試結果調整、配置系統，如此才能讓應用的性能表現一直處於最佳狀態。
在下一篇文章中，我們將分析應用服務器的一般體系結構，回答下列問題：當一個J2EE應用服務器聲稱自己遵從J2EE 1.3規范時，它應該提供哪些功能？它們各涉及哪些可調整的性能因素？
七、附錄：工具軟件
許多集成開發環境帶有完善的測試和監視、診斷工具，但下面只列出一些專用產品。
負載測試工具：
◆LoadRunner，由Mercury Interactive公司開發，屬於最受歡迎的產品之一。
◆Benchmark Factory，由Quest Software公司開發。
◆The Grinder，源代碼開放產品。
監視工具/診斷工具：
◆PerformaSure，由Quest Software開發。
◆Interscope，由Wily開發
◆Indepth，由Precise開發。
