性能監測----關于Java應用程序性能的真實故事

　 對于任何機構來說，保證企業應用程序在性能上達到高標準的兩個基本要求是：具備在負載接近臨界狀態的情況下監測應用程序的能力；具備在故障出現時快速找出故障根本原因的能力，不管應用程序是處于QA，兩階段部署（staging），還是部署階段。

　 　本文的故事都是真實的，文中使用的姓名均為化名。
　
　　本文是一個真正的關于Java性能問題的劇本。首先它概述了Wily企業級Java應用管理解決方案和它在部署前后性能分析中所扮演的角色。然后，我會講述一些性能下降的事例。你將知道為什么忽略Java應用程序管理是得不償失的。

　Wily 4解決方案

　　隨著一個健康發展的機構成熟，它會自發地研究出一系列的策略和步驟來消除它所經歷過?quot;混亂"狀態，這些"混亂"發生在和擔當關鍵任務的Java應用程序的性能問題作斗爭的過程中。這些機構還知道低下的應用程序性能是和巨大開銷緊密相關聯的：IT投入收益率低下、以及在資金流和最終用戶滿意度方面的風險。

　　Wily 技術公司的Wily 4 解決方案允許企業在應用程序生命周期的任何階段監測、改善、管理企業Java應用程序。

　　它提供了一種通用語言，當Java應用程序出現性能問題時，IT機構內的任何部門都可以利用它迅速地識別并修復問題。

　　有了Wily 4，IT小組能夠24/7無間斷地監測應用程序的業務功能，找出資金轉賬、費用支付、商品購買、以及其它核心用例中存在的性能瓶頸--不必修改源碼，所有用例都能被映射到底層的servlets、JSP、EJB、以及實現它們的定制代碼上?？啥ㄖ频哪０婧投喾N集成選項使Wily 4成為主流系統管理解決方案的完美補充。Wily 4允許機構把Introscope警告發布到現有的運行故障解決途徑中，警告中包含了應用程序客戶功能的可用性信息（請參見圖1）。

　

　　Wily 4 解決方案的關鍵組成部分包括：Java應用程序監視器Introscope、用于識別系統潛在內存泄漏的Introscope 泄漏監測器、和解決事務相關性能問題的Introscope事務追蹤器 。Wily 4 解決方案還包含了Introscope SQL代理和Introscope PowerPacks，用于識別Java應用程序與后臺支持系統連接的性能問題。

　　這些解決方案相互結合，提供了一個完整的Java環境下的"整體應用程序"視圖。

　性能監測網：設定并達到性能目標

　　作為一種最佳實踐，一些機構使用Wily的 Introscope來設定基準并記錄應用程序關鍵組件的響應情況，目的是達到性能目標。企業Java應用程序的成功開發和部署應該包括持續的核心用例基線測量工作，而且在開發它們的時候就應該如此。當開發人員對應用程序進行添加和修改時，這些基線可以為評價應用程序的后續版本提供硬性的統計學評價方法。如果不仔細監測開發過程的每個步驟，最后可能會遇到很多的bug，更糟糕的是，遇到體系結構的瓶頸。如果到了兩階段提交或生產階段再修復這些瓶頸，付出的代價將會更大。

　　如同一個優秀的偵探，一個好的基線或基準總是不斷地詢問相同的問題，直到得到滿意的答復。這種處理鼓勵一種"三思而后行"的方法，該方法多次證明自己是提高軟件性能的最有效方法。

　　為了成功加載應用中的所有關鍵用例，應用程序必須已經實現了所有功能；一段好的性能負載生成腳本在應用程序核心功能檢查方面所起的作用相當于出色的一致性檢查的兩倍。
　　
　　一旦應用程序開始在負載下運行，機構們就需要從功能級上不斷監測它的性能，從而識別瓶頸，尤其是在產品階段的頭幾個月中。

　　Wily的Introscope能夠從Java度量中提取細節并轉成真實描述應用程序性能的視圖和報告。在最常見的寵物店例子中，度量是針對產品采購、收據返回、產品目錄察看、以及庫存查找等各個方面的。采用這種方法，調整一個組件的動因不再是因為它運行緩慢，而是因為發現客戶收據返回所需的時間長到了讓人無法接受的程度。如果沒有這樣的視圖，你可能會浪費寶貴的開發時間在性能調整上，但這些性能對于應用程序的整體成功可能無關緊要。

　　Wily的Introscope可以報告調用數量，以及客戶應用程序所有關鍵組件的平均、最小和最大響應時間。Introscope還能夠監測并發情況（對每個方法或業務邏輯組件中線程的監測），并進行內存統計、文件和套接字i/o統計，池化資源利用情況統計（比如，MQ連接）、環境統計、等等。
　　在原型J2EE 應用程序中，充當控制器的servlet、充當模型的EJB、后臺連接器 API (比如JDBC、 MQ Series等等)、以及充當視圖的JSP都將被監測。機構經常采取簡單的附加Introscope定制步驟，這樣就可以在不改變源代碼的情況下監視專有業務邏輯實現或后臺連接器。例如，當Introscope在大型航空公司、電信公司遺留大型機回調、以及無數此類定制后臺系統和業務邏輯中運行時，它完成了監測SABRE事務的任務。

　　來自應用程序的數據可以被記錄到CSV平面文件和主流數據庫中，或者被直接集成到負載生成工具中。

　　每個客戶都可以選擇最適合自己需求的數據記錄和分析方法。寫入文件的數據可以按照配置好的文件容量限制被自動取得，這有助于報告和清除的腳本自動化。一些常用數據庫也包含了能夠獲取可用腳本的示例數據。

　　本文余下的部分將著重闡述一些使用Introscope的真實案例。

　"重要的Sleep"

　　費城，星期一，多云而且寒冷。我值白班?？蛻羰且粋€保險公司，他們的應用程序正在進行兩階段部署。

　　我們監測的程序被稱為AUDIT，它是一個遺留綠屏應用程序的Web前端。
　
　　客戶的保險代理們使用該應用程序建立新的保險單。AUDIT主要使用CICS作為它的后端數據，并根據同樣已經使用了30年的遺留存儲過程來進行新的處理，然后把它們解析成JSP。頁面被設計成在1-2秒內載入，但每次請求都需要花掉7-8秒。來自CICS的數據表明所有的請求都已經被迅速地處理了。那么問題出在哪里呢？我們需要迅速查清原因。

　　運行在應用程序的數據對象解析程序之上的Wily Introscope定制追蹤器顯示：每個事務需要進行50-60次調用，而且每次調用的響應時間恰好都是100毫秒。對數據對象構造過程的調查揭示了開發人員的占位邏輯。

　　每個對象需要一個唯一ID。因此構造函數中編寫了一個100毫秒的sleep，目的是通過調用系統時鐘產生唯一的時間戳。

　結局： 開發人員不再遠程設定sleep時間。

　 "缺陷Bean的冒險"

　　德克薩斯，周二的下午。我和一個客戶在一起，這個客戶費勁地試驗了幾個月想要解決應用程序的性能問題。當我向Watson博士征求意見時，他用一個core dump作為回答。

　　在產品階段，因為響應時間過慢本例中的應用程序可能將會失去30%的用戶采購。很多請求難以置信地需要運行兩分鐘以上，然后就超時了。Introscope很快就在一個方法中發現了性能瓶頸，該方法是用來為采購單條目計算銷售稅的。僅一行的Introscope配置就足以跟蹤本例中被實現的全部業務邏輯接口。
　
　　通過進一步檢查，我們發現該方法使用Runtime.exec調用了一個新的JVM。在進程之外，這個新的JVM計算單個條目的銷售稅，然后把結果輸出到系統輸出上。應用服務器耐心地等待這個輸出，然后，對每個條目重復同樣的事情。在正常負載情況下，多達50-60個JVM被同時啟動和關閉，而每個都需要大約20-40秒的等待時間。

　　我們發現：丟失的事務都是具有多個采購條目的事務，為什么呢？某個開發人員被指派使用包含了EJB接口的第三方稅率計算軟件來完成銷售稅的計算，但他卻無法把該軟件載入到服務器的上下文中。沒有辦法，他只好求助于軟件的示例代碼，于是他把例子改寫成一段腳本，該腳本傳遞適當的參數給命令行程序并且在系統輸出上生成結果。<BR><BR><B>結局：</B>嫌疑人的發現證明了Perl腳本語言的清白。嫌疑人被開除了。本例子結束。

　"然后，什么都沒有了（JDBC游標）”

　　那天是星期三，我距歷史上著名的波士頓公共綠地不遠。在長時間的載入測試過程中，我的客戶總是會用盡所有JDBC游標和MQ Series連接。Wily的 Introscope對分配和回收這些資源的語句進行了監測。借助Introscope的Blame特性，該團隊迅速找出了錯誤的EJB：在高負載情況下，應用程序拋出了異常，結果略過了重要的關閉調用，它們本應該被包含在最后執行的程序塊中從而保證資源的釋放。

　　結局： 現在，丟失的"關閉"已經被安全地放到了最后的程序塊之后。

　"關于同步問題的求救"
　　星期四，我的狗狂叫。喝完了第五杯咖啡，我出門了。

　　Wily的Introscope測出一個專用后臺系統的平均事務響應時間是10秒鐘。

　　但在10個并發用戶的負載測試中，該后臺系統的平均事務響應時間卻在90-100秒之間。這很有意思，顯然后臺系統并沒有并發地處理請求。通過在調用中使用并發度量，我們迅速地找出了缺陷：九個并發的用戶線程在對后臺系統的調用中等待，只有一個線程真正在處理任務。
　
　　Wily 并發度量可以捕獲以下問題：誤把synchronized關鍵字放到class而不是method符號上、應該有10個實例的資源池僅有一個實例、需要被遠程訪問的服務器失去了響應。在這種情況下，應用程序無法處理意外的后臺系統故障，因此會花掉數分鐘或是數小時的時間，從而導致本該在幾秒鐘之內返回結果的調用過期。并發是從應用程序中找出此類缺陷的一個快速而容易的方法，它使我們可以以更優雅的方式在產品階段輕松地處理類似的故障。

　結局： 應用程序以及它的所有者在產品階段工具方面正處于低潮。

　"Maltese 結果集"

　　今天是周五，我在亞特蘭大。街道上與其說有很多樹，不如直接說有很多桃樹。

　　這個客戶在大型數據庫結果集上遇到了麻煩。

　　因為沒有構建一個這樣的策略：它保證查詢能夠被限制，并且以合理的增幅被發放，我的客戶在應用服務器內部引起了一個"pig in the python"內存故障。錯誤的搜索或是查找導致了JVM在GC內存棧上到處橫行。應用服務器費力地按照數據庫給出的樣子讀入結果集，這樣做最嚴重的副作用就是給應用程序其他事務響應帶來了嚴重的外部破壞。

　　通過指出數據庫查詢響應時間和"往返"響應時間不一致，Wily的Introscope SQL代理立即診斷出了故障。后一個度量包含了結果集關閉之前用掉的所有系統時鐘時間，但是前者僅包含了捕獲數據庫回應所花費的時間。往返響應次數和相應的度量之間存在很大的分歧。當然，這種度量只有從應用服務器內部才能捕獲。

　結局： 開發團隊進行了必要的修改?，F在該應用程序被徹底改造了，并在社會中發揮著自己的作用。

　"謀殺JDBC Express"

　   我自愿周六在舊金山工作。最后一個客戶訪問了Vegas之后，我需要加班了。

　　我不知道自己的JDBC災難離結束還有多遠?？蛻粢呀洿蟾胖懒巳绾握{整關鍵數據庫事務的響應時間--JDBC語句被測出大概平均需要10毫秒，大多數在上下1毫秒內浮動。

　　那些超出范圍的事務是怎么回事呢？我對應用程序使用了Introscope 事務追蹤器，并且記錄到了在標準負載下出現的一個30毫秒的事務。

　　在以前，沒有任何整合工具可以幫助用戶找到"有罪的"方法?，F在，事務追蹤器調用圖形，利用Introscope自動除去無關的數據，使客戶能夠看清森林里的每一棵樹：一個單獨的事務引發了差不多4000條JDBC語句。即便數據庫響應迅速，這么多的查詢也足以造成故障。

　　事務追蹤器的分析表明：每個校驗方法負責處理六條來自調用的JDBC語句--對該方法的調用在每個事務中占據了幾乎40%的JDBC 語句。開發團隊進行了少量的修改--不到一天的工作量--使用緩沖策略來實現這些校驗。CPU占用和處理時間都降下來了；生產率得到了提高。

　結局： 數據庫得到了完全的修復，但是從那以后，這個開發團隊就被指定開發Swing了。

　"知道得過多的Vector" 星期六的晚上，漫長一周的結束。城市的燈光透過濃霧射了出來。當我正在倒一杯黑麥威士忌的時候，電話鈴響了。
　
　　這個客戶擁有一個基于J2EE的貿易系統架構，其中的調用是直接針對EJB遠程接口的。幾個月前，他們更換了JMS實現，現在遇到了CPU過載和生產率下降的問題。"GC Heap Bytes in Use"伴隨著每個事務不斷地出現，并最終導致了內存不足異常。
　
　　開發團隊試驗了所有常用的整合工具（profiling tool），但沒有一個能夠發現泄漏的根源。（請參見圖3）

　   
　　

　　Wily Introscope泄漏監測器很快就發現在一個Vector中存在反常增長--該Vector僅僅是應用程序使用的45000種數據結構中的一種。存在問題的Vector中含有事務標識符，它為快速回滾進行臨時緩沖。當應用程序中事務數量增長的時候，Vector也隨之增加。當對Vector 調用"contain"的時候，新的JMS實現引起了一個出乎意料的結果。這個錯誤說明，調用"contain"導致了每個事務都增加了條目，而新增事務又會引起Vector的增長。

　結局：

　　討厭的Vector現在已經被Victor這個名字取代，而且它正良好地運行在佛羅里達的目擊者保護程序中。<BR>結束了長長的告別，我走進夜色之中。我不知道下一個案例將會在哪里發生。

　作者簡介
　　Dave Martin是Wily技術公司的一位系統工程師。他曾經為很多企業客戶工作過，主要工作是鑒別并修正Java應用程序的性能問題。作為Wily技術公司的一位前軟件開發人員，Dave具備廣泛的J2EE體系結構、軟件系統設計和實現方面的知識。

原文轉自：http://www.kjueaiud.com