大多數應用程序性能管理（APM）解決方案都只考慮和分析J2EE應用程序的某個層次的性能問題。這種方法不足以解決架構復雜的應用程序的性能問題。良好的APM工具應該能夠讓你從J2EE層深入到數據庫層以確保性能問題被快速地解決。
情況並非越來越好，公司的網站性能下降到了極低點，失落的客戶開始尋找其它廠商了。IT調查機構開始調查並且認為J2EE應用程序是響應時間較差的罪魁禍首。這立即給J2EE開發小組帶來了很大的壓力，他們必須確定並解決這個問題。
J2EE開發小組在進行了一些最初的調查之後，他們認為問題並不是出在J2EE層，而是一直可以跟蹤到數據庫中。但是數據庫小組反駁說問題實際出在J2EE層。相互之間的責備不斷增加，小組合作精神消失了，混亂開始流行，客戶和收入持續減少。
上面的這種情況突出了一個重大需求：為了支撐J2EE和數據庫層之間更好的交互操作能力，IT部門必須能夠快速和果斷地做出決定。
基本的挑戰：找出問題的起因
當響應時間的延遲趕走了Web站點的用戶的時候，J2EE開發者就不得不加入這個相互責備的游戲中了。在中間層開發應用程序的程序員必須與數據庫交互操作，當性能瓶頸出現的時候，如果數據庫是下層的起因，問題也顯示在J2EE層。其實真正的問題在於交互操作。如何最好地調節這兩個層次之間的綜合關系以獲取應用程序的最佳性能？更深入一點，如何查看這些瓶頸、識別真正的問題起因，並盡可能快地處理這些問題呢？
很多APM（應用程序性能管理）工具都可以輔助我們識別和解決這些性能問題。查找J2EE應用程序中的瓶頸的最常用的兩種方法是：
1、使用帶不同顏色警報的儀表程序來監視系統的狀態。綠色的意思是良好的，黃色或紅色意味著你必須處理性能問題了。這個儀表程序還可以報告系統中不同的組件的響應時間。
2、不是等待性能惡化到一定程度才去跟蹤儀表程序的警告信息，而是采用預先防護的方法並試圖識別出過多的響應時間或資源使用。你可以通過檢查頂層服務請求（根據響應時間）並進一步分析它們調用了什麼組件來實現這樣的操作。
假設有一個銀行系統。一個查看帳戶信息的顧客訪問了你的Web站點以獲取過去七天自己的帳戶的概要信息。該顧客點擊了"獲取帳戶概要信息"鏈接。
獲取帳戶概要信息的過程是通過Web浏覽器調用某個特定的URL來完成的。當然，在下層，它調用了很多組件，這些組件交互操作來提供正確的輸出信息。在查找瓶頸的過程中，你從頂層的調用（可能是doGet()或doPost()方法）開始，循著調用樹查看"獲取帳戶概要信息"服務調用的所有組件，接著查看這些組件所調用的組件，一直到最底層，在很多情形中，它可能是使用JDBC（Java數據庫連接）調用數據庫的SQL語句。
你必須知道這些組件中哪些花費的時間過長了，但是采用這種方式逐步分析的時候會花費很多時間，經歷很多煩心的過程，在你對它們中個別角色不是太熟悉的時候尤其如此。你必須查看每個組件，並詢問自己它花費的時間是否太長？用10秒鐘來生成輸出信息以響應 "獲取帳戶概要信息" 是必須的嗎？你也不是特別肯定，因為如果要了解這些信息的話，你必須知道下層的每個方法或程序組件是如何運行的細節信息。唯一知道這些信息的人恐怕只有某個特定組件的開發人員。如果你懷疑問題出在數據庫的響應時間上，那麼就需要聯系數據庫小組進一步研究這個問題。 隔離SQL語句
假設檢索帳戶信息花費了太長的時間。每個請求帳戶概要信息的用戶需要等待15秒才會有響應。那麼問題會出在數據庫一方嗎？有沒有可能是應用程序代碼的問題？網絡的問題？甚至於可能是該用戶的互聯網連接太慢的問題呢？
但是，在這種情況下你如果懷疑是數據庫檢索的問題就是應該受到責備的。查找起因的一個方法是讓APM工具顯示應用程序發出的所有SQL語句，按照響應時間進行排序，這樣你就可以看到某個SQL語句是否因為出錯的原因花費了太長時間（有些SQL語句會花費很長時間--例如按帳戶檢索一年內所有事務的列表）。
現在你查看一下位於列表頂部的SQL語句。它進入數據庫並花費了1秒鐘響應。這樣的性能不是太差；如果這是性能最差的SQL語句，那麼問題可能根本不在SQL語句中。因此，接下來的問題是：是不是應用程序層出了什麼問題呢？誰在調用這個語句？調用了多少次？如果某個應用程序調用SQL語句的次數超過了你的預期，你就有理由懷疑應用程序出了故障。
APM工具這次又可以幫助你了。你可以簡單地點擊該SQL語句，會出現一個鏈接，顯示出它的整個調用樹，從顧客請求帳戶概要信息開始，到進入數據庫的SQL語句為止。現在你擁有了兩部分信息：你能肯定自己在查看該服務請求的某個特定請求；你可以看到每個獨立的組件對響應時間的影響。
現在你可以查看調用該SQL語句的組件說明，並且你發現它的響應時間是9秒鐘。很明顯，它是造成客戶等待15秒鐘的主要因素。APM工具顯示的列表同時顯示出這個組件7次調用了該SQL語句。這就告訴你9秒中大部分是調用SQL語句消耗的。該組件不僅執行了過多的計算，還多次調用了SQL語句。這樣的操作可能有些很好的原因，但是任何性能管理工具都不能說明其起因。最重要的是你已經指出了必須進行調查的程序組件。良好的APM工具還可以為解決這個問題提供一些建議。
真的是數據庫的問題嗎？
讓我們從另一個角度來看這個問題。假設該組件並沒有多次調用SQL語句，它只調用了一次，但是這次調用卻消耗了15秒中的大部分。現在的問題是，為什麼單個語句需要那麼長時間執行呢？這個問題不在代碼中，因此它可能在數據庫那一端。
你現在需要的是性能管理工具允許你對特定服務請求（獲取帳戶概要信息）的調查深入到數據庫層。請返回你得到的SQL語句列表，點擊你感興趣的SQL語句的鏈接，它會把你從J2EE端帶到數據庫端。現在你在查看Oracle數據庫或其它數據庫產品環境中的SQL語句。該工具可能幫助你查明數據庫端的問題，還可能提供一些專業的調整建議，數據庫管理員（DBA）可以使用這些建議來提高數據庫的性能。問題可能出在存放數據表空間的磁盤性能較差，建議把它移動到另一個磁盤上；也可能是丟失了某個索引，你可以通過建立新索引來提高速度；也許是數據庫上並行運行了太多的線程，你必須對這些線程進行隔離以減少並發性問題。
還有其它一些可能性。數據檢索可能花費太多的時間，因為花費了很長時間等待獲取數據庫連接。代碼是良好的，數據庫運行也正常，但是這樣的等待時間可能告訴你數據庫連接池不夠大，無法處理大量的甚至於正常的通訊。你可以查詢應用程序服務器，了解已經定義了多少個連接，把這個數字與典型的並發請求數進行對比，很快就可以確定是否需要更多的連接了。
提高交互操作能力
你的性能管理工具不僅需要識別出J2EE層響應時間的構成因素。它還應該能夠讓你看到J2EE層和相鄰的數據庫層之間的交互操作情況，並為分析這兩個層次上的性能問題提供方法。為了高效率地處理性能問題，J2EE開發者和DBA使用綜合的APM產品是必要的。它同時還讓J2EE和數據庫小組"用同一種語言說話"。大多數APM解決方案的目標都是架構體系中的單個層次，為單個層次提供診斷信息。使用這種方法的時候，時間會浪費、相互的責備會形成風暴、而且經常還是無從解決問題。今天復雜的架構和老練的技術意味著某個層次與其它層次之間的交互操作所導致的性能問題用這種途徑是無法定位的。現在我們能夠使用的最主流的APM工具允許我們從J2EE層跟蹤到數據庫層，以確保及時地解決性能問題，而不論問題來自於哪個層次。
結論
提高J2EE層和數據庫層之間的交互操作能力帶來了明顯的優勢：加快最終用戶的響應時間、增加顧客的忠誠度、提高士氣、服務的底線也更高了。現在我們可以使用的高級工具填補了J2EE層和數據庫層之間的裂痕，自動地搜索瓶頸，查明起因，並為解決問題提供專門的建議。每個J2EE開發小組都應該認真地考慮這些綜合的APM工具給它們的生產帶來的價值。
