最大化J2EE和資料庫互動操作效能

j2ee|互動|資料|資料庫|效能|最大化

概述：

大多數應用程式效能管理（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工具給它們的生產帶來的價值。