概述：大多數應用程序性能治理（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工具還可以為解決這個問題提供一些建議。
真的是數據庫的問題嗎？
