提高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開發小組都應該認真地考慮這些綜合的AP
M工具給它們的生產帶來的價值

注：以上內容來自網路， 本人不承擔任何連帶責任

文章轉自：http://se.csai.cn/media/200803111629011638.htm