|
本文譯自：www.
原文名稱《Monitoring Performance with WebSphere》
原文作者：Ruth Willenborg
原文鏈接
我們聽過電子商務站點在沉重的負載下崩潰，花費公司數以億計美元這種可怕地故事。我們在等待某個Web頁面下載時遇到過失敗，不得不尋找執行速度更快的站點。
Web站點的性能就是業務量。執行效率差的Web站點會引起客戶不滿，失去賺錢的機會。因為這些原因的存在，使監視Web站點的性能，識別性能故障，快速找到起因并解決問題成為所有Web站點操作中關鍵的部分。本文將提供使用IBM WebSphere Application Server（WAS）進行Web站點性能監視的綜述。
監視的尺度
成功的性能監視幫助你檢測和糾正性能問題。在定義監視方案前，需要考慮下面一些因素：
◆ 如果你沒有測量性能，就不知道有問題。
◆ 如果你不知道在哪兒測量性能，就找不到問題。
◆ 如果你不知道怎樣找到問題的源，就無法修復問題。
在我們仔細分析性能監視之前，我們簡單了解一下三種監視尺度--最終用戶視圖、系統和應用程序健康、應用程序視圖。
最終用戶視圖。對于最終用戶來說，你的Web站點是一個黑盒子。他們不知道（或不關心）有多少服務器、服務器在哪兒、服務器的硬件如何或者服務器使用哪種應用程序。用戶只關心Web頁面的顯示速度。監視最終用戶視圖可以讓你知道是否存在公共可視方面的性能問題。如果Web站點太慢，客戶將放棄并離開。不應該等待客戶抱怨才發現站點有問題。
系統和應用程序健康。第二個監視尺度是查看Web站點的內部子系統并檢查每個的問題。典型的WAS Web站點有很多子系統，包括Web服務器、應用程序服務器、數據庫、目錄服務器和防火墻。任何一處都可能成為瓶頸！
在這個階段，你試圖找到有問題的組件并識別受限制的資源。你可能發現網絡帶寬、后端連接、數據庫的CPU或其它組件，它們中的任何一個都可能是資源的瓶頸。因此，你必須監視所有的組件，包括應用程序服務器、數據庫、網絡和路由器。查看關鍵的因素并與正常的（預期狀態）比較。如果找到了偏差，就更精確地調查這些部分。
系統健康視圖經常提供了對受約束資源的認識，但是對于識別問題的根本起因不一定是充分的。對于運行在Java虛擬機（JVM）上的Java 2企業版（J2EE）應用程序代碼來說這種情況很明顯。例如，如果系統健康監視發現運行應用程序的服務器的CPU利用率很高并且某幾個小服務程序的響應時間很長，實際根本的起因可能是應用程序中的某個不好的循環、同步問題或者數據庫索引丟失。為了解決這個問題，你必須獲取更多的信息來找出問題。
應用程序視圖。第三個監視的尺度是查看應用程序內部來幫助查找困難的應用程序問題。在某個快照提供給定實例的所有Java線程活動信息時，應用程序視圖可以給你精確顯示某個緩慢的小服務程序正在做什么的信息。深入查看應用程序的內部執行對于查找困難的性能問題是很重要的。
監視什么
在最終用戶視圖尺度上，監視站點的"用戶負載"、服務的事務和用戶經歷的響應時間。這些都是相同的基本監視數據點，你能在預生產性能和壓力測試中捕捉到這些信息。
監視最終用戶視圖使你能追蹤Web站點的響應時間是否在增加，請求是否在增加以及增加的速度，增加是否是正常的、預期的狀態。監視的三個主要因素是：
1、負載（并行用戶的數量）
2、響應時間
3、輸出（每秒鐘的請求數量）
圖1：負載、響應時間和輸出之間的預期關系
圖1顯示了這些規格之間的預期關系。A部分是輕負載區，顯示隨著并行用戶請求的增加，輸出幾乎直線增長。在某個點開始出現擁擠并且輸出增長率很慢，一直達到某個飽和點，這個階段稱為輸出平穩段，它表現了輸出值的上邊界。其最大值由瓶頸決定--典型的情況是Web站點上飽和的資源。B部分是重負載區，隨著客戶端請求的增加，輸出相對不變，但是用戶載入的響應時間相應地增長。如果請求的數量加倍，響應時間也會加倍。C部分是波浪區，在某個點一個系統組件被耗盡。此時，輸出開始降低和響應時間增加的速度比直線還要快。
通過檢測用戶請求的數量、輸出和響應時間，你能夠知道站點顯示的正常響應時間是否根據請求的容量而增加，或者必須仔細研究響應時間問題。例如，大量的并行客戶端載入的測試結果顯示當并行用戶翻倍（從10個增加到20個）時，平均響應時間也翻倍（從150毫秒到301毫秒）了（圖2所示）。如果你監視到響應時間和用戶請求都翻倍了，應該是站點的正常狀態。監視器顯示你有更多的負載，因此響應時間相應長一些。在實際運行前有效的性能測試和能力計劃能幫助你確定站點的飽和點。
圖2：40個客戶端測試的最終用戶響應時間
如果站點接收到的增長的負載超過了計劃估計的容量，考慮使用縮放技術處理過多的負載，同時維持響應時間不變。但是，如果監視顯示響應時間翻倍了而請求沒有成比例增加，你就必須使用到第二種監視尺度--系統健康，以找到系統中是否有未預計到的約束，以及在哪兒找到問題所在。
檢測響應時間問題
系統健康監視對于檢測組件層的響應時間問題是很關鍵的。有很多監視器可以用于檢測環境的全面健康狀況、趨勢并幫助解決問題。每個生產站點必須開發一個監視測量并決定對Web站點的每個組件使用哪種關鍵的監視器。
監視系統健康使你了解Web站點上所有組件的關鍵信息，幫助你定位受約束的資源。一旦找到了這些資源，需要進一步發現和解決約束的起因。對于WebSphere應用程序，檢查應用程序統計表和Web應用程序監視器、中間件運行時監視器和服務器監視器。本文沒有仔細討論討論所有的監視器。
Web應用程序監視器。 前面我提到，在最終用戶視圖中，并行請求、響應時間和輸出是用戶角度的標準。這三個主要的因素對于Web應用程序組件（例如Web頁面、小服務程序、企業JavaBean）的每個服務器層來說也適用。查看每一層的響應時間和請求數量能幫助你識別可以在哪兒找到問題。例如，如果應用程序服務器上的響應時間和請求數量顯示正常，你就知道將研究焦點集中于Web服務器、網絡和客戶請求與應用程序服務器之間的其他組件。
對于典型的WAS開發，用戶的請求通過HTTP服務器傳遞，接著調用在應用程序服務器上配置的一個小服務程序。你可以監視HTTP服務器和應用程序服務器上的應用程序性能。根據特定的監視工具和使用的HTTP服務器，你可以監視HTTP服務器的任何一個或所有三個主要因素。
40個客戶端負載的狀態快照運行并顯示，在這種特別的刷新間隔中，處理了40個請求。不幸的是，這個特定的Apache監視工具沒有提供把計數器復位為0的簡單方法，因此總共的訪問（請求）和每秒鐘的請求覆蓋了整個6個小時的服務器周期，并且沒有與WebSphere監視器相應的時間間隔。
監視器為每個應用程序服務器負載、響應時間和輸出。圖5顯示了一個使用資源分析器（Resource Analyzer）的小服務程序化監視器快照。這個圖表顯示了40個客戶端運行的應用程序服務器因素，顯示在應用程序服務器中并行請求的平均數量在35到40個之間，平均響應時間小于600毫秒。你能使用整個請求計算每秒鐘的請求數（圖2中與40個客戶端負載測試相應的這些規格的最終用戶響應時間為635毫秒）。
圖3：40個客戶端運行的應用程序服務器各因素
中間件運行時監視器。你可能需要通過監視緩沖池的利用請求，監視Web站點上流動的請求的健康。圖4顯示了一個典型的查詢網絡。對于查詢網絡中的每個緩沖池或容器，你查看利用情況。對于IBM HTTP服務器，你監視當前正在處理的請求和空閑服務器。
圖4：WebSphere查詢網絡
你也能監視Web容器的線程池--對象請求代理程序（Object Request Broker，ORB）和數據庫連接池。如果任何一個緩沖池達到了最大的容量，它就可能阻塞了業務流。通常，較大對于性能不一定更好，因為額外的容量浪費了資源。因此，隊列和緩沖池的適當協調對于最佳性能是很重要的。
圖5：Web容器線程池監視器
圖5顯示了Web容器線程池的快照，它的默認線程池設置為最小25，最大50。如果你運行40個客戶端負載，線程池建立的補充線程高于最小的25個，平均運行38個線程。該緩沖池永遠不會達到最大容量50。一旦線程建立了，它們中的大多數就在使用中，結果很少線程被消除。這個圖表顯示了Web容器線程池的較好的情況。
圖6：較差的動態線程池示例
相反，圖6（它是故意做的）顯示了效率低下的Web容器池。在這個例子中，40個客戶端負載運行在線程池設置為最小、最大都是2個線程的Web容器上運行。此外，我選擇了當緩沖池超過最大容量時增加。你可以看到，緩沖池大多數時間運行在最大容量上。因為在超過最大容量時我允許緩沖池增長，建立和消滅數以百計的容器線程使系統失效了。
對于所有的WebSphere線程和連接池，高百分比的最大值顯示特定緩沖池可能引起瓶頸。你能使用另外的監視器（例如緩沖池尺寸）和活動線程來幫助協調緩沖池。
服務器監視器。中間件和Web應用程序在下層服務器上執行。你必須查看所有服務器（包括Web服務器、應用程序服務器和數據庫服務器）的系統監視器--CPU利用率、I/O和分頁。
應用程序視圖：Java應用程序
當引起性能問題的原因在Java應用程序中的時候，你必須能夠監視在JVM中執行的應用程序內部發生了什么事情以識別有問題的源。典型的應用程序視圖層次的監視需要大量的J2EE編碼和具體應用程序的相關知識。解決表面上是負載問題的Java應用程序問題可能需要這個層次的監視。你可以從兩個角度分析運行在WebSphere上的應用程序：（1）應用程序調用流和響應時間情況，（2）線程狀態執行情況。
從應用程序調用流角度看，你需要查找消耗最大響應時間的應用程序部分。調用流可能顯示某個小服務程序作了多重EJB調用，而每一個EJB調用作了多重JDBC調用。分析調用流使你識別了應用程序消耗最多時間的部分。圖7顯示了HitCount應用程序調用流的一部分。這個例子顯示，JDBC響應時間大約為1毫秒--是整個響應時間中很小一部分，顯示JDBC調用不是性能問題。
HitCount Servlet Service method (24 ms) ->
Inc Bean Increment method (22 ms) ->
DBPreparedStmt executeUpdate (1.28 ms)
DBPreparedStmt executeQuery (1.04 ms)
|
示例應用程序調用流
作為分析應用程序調用流的補充，你可以檢查JVM中的每個線程的狀態。線程狀態執行情況監視某個時間應用程序內的每個線程的行動。通過查看線程棧中的結構，可以識別并行瓶頸。例如，我修改了HitCount小服務程序來調用緩慢的同步日志程序（通常的問題）。在運行修改過的HitCount時，執行了線程轉儲。運行50個線程時，39個是棧頂部結構，9個在等待來自Web服務器的工作。線程棧信息使你能與Web應用程序程序員一起排除可伸縮性瓶頸。
接口和加工
大多數操作系統和應用程序包含了接口以獲得關鍵的性能指示并為監視性能提供基礎的工具。此外某些行業方案有具體產品的性能接口以提供端對端性能監視方案或者專業的監視方案。
WAS運行是允許輕量級的、關鍵的運行時和Web應用程序性能因素的服務器端性能數據集合。WAS的一部分--性能監視基礎結構（PMI），支持多種客戶端檢索選擇，包括Java和HTTP/XML接口。
維持最佳的性能
性能監視對于Web站點的成功是很關鍵的。了解每個監視尺度的角色將幫助你在性能問題反面影響Web站點前識別、定位和解決它們。有了WebSphere API和支持工具，你能監視每個尺度來確保Web站點的性能最佳
|
