本文的目的是說明如何在典型的J2EE環境下實現可伸縮性測試，性能測試和優化。
定義
響應時間——從初始的請求到回應下載的完成（刷新整個網頁）之間的時間。
負載——系統使用的尺度。當服務器的應用可以承受繁重的通訊量時被稱為可以承受“高負載”。
可伸縮性——可伸縮的應用應該擁有隨負載線性增長的響應時間。這樣的應用可以通過線性的（不是指數性的）增加硬件設施來處理越來越多的數據量。
自動測試工具——通過模擬用戶請求網頁或在你的網站上遍歷預編程的工作流（鏈接）的工具（如Segue軟件的Silk，WebLoad等等）。
負載測試工具——大多數自動測試工具同時也是負載測試工具，如WebLoad。這些工具可以模擬任意數量的用戶使用你的站點，并且可以提供重要的分析數據如平均響應時間等。
Profiler（程序刨析器）——Profiler是在你的應用程序運行時進行檢測的程序。它能提供你有用的運行時刻信息如特殊代碼塊的運行時間，內存/堆利用率，內存中特殊對象的實例數目等等。
性能測試的過程
1） 功能測試。大多數應用程序的測試首先是對完成功能的測試。即確保應用程序中所有的測試用例/工作流正常工作。
2） 負載和可伸縮性測試。負載和可伸縮性測試有兩種方式：
☆ 在增加數據庫數據量的同時測試響應時間。
☆ 在增加當前用戶數量的同時測試響應時間。
3） 解釋結果。在各種數據庫容量和不同的負載下測試過響應時間后，就可以在這些測試的平均響應時間和測試中服務器的資源利用率的基礎上來做出解釋。
4） 優化。在上一步完成后識別出問題所在，然后解釋結果并捕捉問題。
負載和可伸縮性測試
負載和可伸縮性測試的目的是確保你的應用程序在使用的高峰時期擁有較好的響應時間。你還可以測試你的應用程序在超載時的行為（因為你的站點的數據庫中會有越來越多的數據）。在測試之前，先編寫一些腳本，向數據庫中填充平均數量的數據，運行性能測試，測量響應時間。然后向數據庫中填充大量的數據（大約是三年內可預見數據量的三到四倍），再次運行性能測試。如果第二次測試的響應時間特別長，那么肯定有問題。
在進行性能測試時，你可能會想模擬不同負載下服務器的使用情況。根據經驗，可以模擬低負載（1-5并發用戶）、中負載（10-50并發用戶）、大負載（100并發用戶）和重負載（1000以上并發用戶）。注意這些數字是不確定的，根據你的商業需求而定。另外，使用負載測試軟件模擬10個并發用戶并不就真正代表了10個并發用戶，因為在負載測試中每個“機器人”在再次命中服務器之前會等待幾個毫秒。這樣的話，使用負載測試工具模擬10個并發用戶差不多代表實際網上沖浪中的30-40個用戶。
在測試過了這三種負載級別后，就可以比較在這幾種情況下的平均響應時間，考察你的服務器是否可承受大訪問量，即平均響應時間是否線性增長。
解釋結果
性能測試過程中最有趣的就是解釋負載測試的結果。讓我們來看看幾種不同的可能性：
1．當數據庫的數據量大量增長超過一定程度時，響應時間延長很多。
當數據庫中的記錄從100行增加到50，000時，響應時間不應該有明顯的增加。數據庫索引技術使得從表中查找一條記錄只需耗費幾毫秒的時間，即使該表有成千上萬條記錄也一樣。這就是說，從一個適度數據量的數據庫增加到擁有超量數據的數據庫時，如果響應時間大大延長，那么你可能還沒有索引適當的列。
2．負載增長時響應時間呈指數化增長
如果在增加并發用戶數量時系統變得不可用，那么你的系統就不是可伸縮的。這個結果的解釋比較困難，因為問題原因可能是硬件、發布平臺的配置、系統體系結構等等。一定要在測試過程中監控以下服務器資源：
☆ 監控內存請求。
☆ 監控CPU使用情況。
如果CPU是超負荷使用的，就需要更快的或更多的處理器。如果CPU利用率比較低，那么就可能是相關的輸入輸出問題，檢查測試系統的數據庫連接、線程數、網絡配置等等。
檢查過配置，確定不是硬件瓶頸，體系結構和代碼都經過了優化，如果問題仍然存在的話，就該進行代碼運行時監測了（使用profiler）。
優化
數據庫、體系結構、配置和硬件都是需要優化的對象。上面已經提過，導致服務器負荷承受能力低的最簡單的失誤就是數據庫沒有經過優化。數據庫管理員（DBA）對任何開發組來說都是至關重要的，如果沒有的話，可以考慮這樣做：
察看所有的EJB，核實數據庫沒有執行任何編碼的SQL語句的線性搜索?？梢钥截惔a中的SQL語句到數據庫的SQL查詢工具窗口中，執行EXPLAIN子句：
Explain select * from table where tablefield = somevalue
盡管Explain的語法根據數據庫的不同各有差異，但總有一些東西是相似的。數據庫會告訴你該語句是根據索引查詢還是線性查詢。確保驗證了數據庫的每一個SQL語句都使用了索引。如果沒有使用，建立索引。
優化數據庫后再優化硬件配置，下一步再使用profiler優化代碼。
Profiler程序在你的應用程序運行時分析它，并提供給你使用其它方法無法得到的信息，如：
1．每個類在內存中有多少個對象和垃圾收集器的行為。
☆ 這些信息可以幫助你識別那些類應該被緩存。
☆ 可以幫助你調整Java內存堆。
2． 應用程序在具體的類中花費了多少時間。
這是非常重要的特征。Profiler可以指出那個類是瓶頸。
有一個這樣的profiler程序叫做Optimize-It。Optimize-It可以用于任何Java程序或基于Java的應用服務器。它可以很容易的和WebLogic配置到一起，也可以用來刨析遠程服務器上的應用程序。
優化體系結構和具體的項目密不可分。不過其中有一些小的技巧：
⑴．確保網絡調用最少，特別是數據庫調用。
☆ 一個大的數據庫調用比很多小的調用要好得多。
☆ 確保ejbStore沒有為只讀操作保存任何信息。
☆ 使用Details Objects獲取Entity Bean狀態。
⑵．確保在盡可能的情況下利用Cache。
應用服務器可能允許在內存中使用Entity Bean緩存，確保利用了這些特征，因為它可以顯著減少數據庫調用并加速數據存取。
⑶．確保使用Session Bean作為Entity Bean的封裝。
可以把一個完整的實例的工作流封裝到一個網絡調用中，作為一個Session Bean（和一個事務）的一個方法。
結論
應用程序的性能測試與優化是一個挑戰。幸運的是，市場上有很多工具可以使這個過程變得簡單。使用這些工具按照本文提到的簡單步驟，你可以有效的捕獲系統的瓶頸所在。