性能問題的最明顯表現是網頁的響應時間變慢。在J2EE系統中，經常體現有下面更為基本的症狀：
應用服務器資源的使用情況
JVM堆的使用情況
系統資源的使用情況
數據庫資源的使用情況
網絡活動
這些現象表明J2EE應用依賴很多外部資源，並且是運行在一個層次化的執行模式的環境中：
由於Java虛擬機和應用服務器掩蓋了操作系統和硬件的特性，所以在設計軟件系統時，架構工程師更應該深刻理解整個操作環境。
在設計軟件系統時，架構工程師應把性能和可擴展性放在首位，然後開始尋找容易解決的問題，反應時間緩慢通常的原因是訪問數據庫效率低和過多地調用遠程對象和方法。接下來，架構工程師可繼續尋找不明顯的原因，例如算法的累積影響和不必要的開銷。
現在市場上的各個J2EE應用服務器有很多配置項目。這裡只簡單介紹一些常見的性能優化配置項目。
很多應用服務器都有一些與J2EE規范有關的操作系統配置項目或非標准的特性，這可以提高系統性能。應該化時間來理解這些性能配置。
Java虛擬機堆和垃圾回收設置
任何Java應用的性能調整基礎都涉及到堆的大小和垃圾回收設置。（這裡主要討論Sun HotSpor JVM）.
堆可分為三代，年輕的（新的），年老的和持久的。Hotspot JVM的內存基本配置包括最大堆大小，初始堆大小和年輕一代堆的大小。當配置最大堆大小時可參考下面一些指導：
最大大小應小於物理內存，避免虛存的頁面調度。
需要減去其他進程使用的內存
在負載測試時進行優化
注意不要將最大堆大小設置得過大。堆越大，內存中保存的對象越多。內存中對象越多，回收過程時間越長。
配置初試堆大小的一般性策略包括：
將初始大小設置為最大堆大小
將初始大小設置為最大堆大小的1/4到1/2
對於年輕一代堆大小，Sun 推薦是設置為最大堆大小的1/3。
也可以選擇不同的垃圾回收算法。首先是增量垃圾回收。該算法的意思是減少單個對象回收停頓時間，這樣的結果是整體回收性能的下降。該算法將相互引用的對象分組，然後嘗試按組回收。嘗試回收的部分越小，回收處理的時間往往會越少。
1.4.1版的HotSpot JVM增加了兩個垃圾回收算法：並行算法和並發算法。
在年輕一代堆中實現了並行算法。在多處理器的機器上，這種回收算法使用了多線程來提高性能。雖然這個算法會暫停所有的應用線程，但是由於利用了多個CPU使得回收時間非常快。在年輕一代堆中，該算法顯著地減少了回收帶來的停頓。
在年老一代堆中實現了並發算法。在應用中最大限度地執行並發。回收過程分為4個階段，覆蓋了可回收對象的標記和清除操作。前兩個過程會暫停應用線程，後兩階段可與應用並發執行。並發垃圾回收算法的"最大限度並發"特點可以使JVM利用更大的堆和多個CPU。因此應關注由於采用缺省的mark-compact(標記-壓縮)和stop-the-world（停頓所有處理）等垃圾回收算法所帶來的延遲和吞吐量問題。
處理線程
J2EE應用服務器是多線程的應用。應用服務器的線程是一種資源池，處理請求和和應用服務器的內部功能等任務共享這些資源。
很多應用服務器允許為特定的任務或應用配置不同大小的線程池。通常需要增加這些線程池的大小以滿足應用負載的需要。
架構工程師應該避免將線程池大小設置過大，這是因為會增加上下文交換的次數，從而降低應用的性能。線程池的大小通常應該能最大利用機器上的CPU，同時又不能使CPU過載。
EJB配置項目
在應用服務器中，很多不同類型的EJB是以資源池的方式實現的。通常這些池大小和初始Bean的數量會明顯影響應用的性能。
架構工程師應該避免將這些池大小設置的過大，這樣會導致不必要地消耗JVM和操作系統內存。另外，將初始Bean數量設置過高會使得應用服務器的啟動時間長的難以接受。
在應用服務器中，緩存很多不同類型的EJB。緩存大小和超時設置通常也會對應用性能帶來顯著影響。
架構工程師應該避免將緩寸大小設置過大，這同樣會不必要地消耗大量JVM和操作系統內存。此外，應避免設置過長的超時--例如當EJB不用時，仍被緩存---，這也會導致不必要地消耗大量內存。
數據庫配置項目
J2EE規范要求應用服務器廠商必須提供數據庫連接資源池功能。通常增加數據庫連接池的大小會提高性能。架構工程師應該考慮不同類型的SQL操作（例如事務型和批處理型）應使用不同的連接池。如果一個消息Bean執行批處理操作，那麼應該為此另創建一個連接池，而不要與事務型操作使用同一個連接池。
很多J2EE應用服務器提供了Prepared Statement 的緩存功能。創建Prepared Statement是很耗費資源的。在事務型的J2EE應用中通常執行很多同樣的SQL語句，只是參數不同而已。所以在應用中應發揮數據庫配置項目的作用，盡量使用Prepared Statement。
