本文譯自：www.

　　原文名稱《Monitoring Performance with WebSphere》

　　原文作者：Ruth Willenborg

　　原文鏈接

　　我們聽過電子商務(wù)站點在沉重的負(fù)載下崩潰，花費公司數(shù)以億計美元這種可怕地故事。我們在等待某個Web頁面下載時遇到過失敗，不得不尋找執(zhí)行速度更快的站點。

　　Web站點的性能就是業(yè)務(wù)量。執(zhí)行效率差的Web站點會引起客戶不滿，失去賺錢的機(jī)會。因為這些原因的存在，使監(jiān)視Web站點的性能，識別性能故障，快速找到起因并解決問題成為所有Web站點操作中關(guān)鍵的部分。本文將提供使用IBM WebSphere Application Server（WAS）進(jìn)行Web站點性能監(jiān)視的綜述。

　　監(jiān)視的尺度

　　成功的性能監(jiān)視幫助你檢測和糾正性能問題。在定義監(jiān)視方案前，需要考慮下面一些因素：

　　◆ 如果你沒有測量性能，就不知道有問題。

　　◆ 如果你不知道在哪兒測量性能，就找不到問題。

　　◆ 如果你不知道怎樣找到問題的源，就無法修復(fù)問題。

在我們仔細(xì)分析性能監(jiān)視之前，我們簡單了解一下三種監(jiān)視尺度--最終用戶視圖、系統(tǒng)和應(yīng)用程序健康、應(yīng)用程序視圖。

　　最終用戶視圖。對于最終用戶來說，你的Web站點是一個黑盒子。他們不知道（或不關(guān)心）有多少服務(wù)器、服務(wù)器在哪兒、服務(wù)器的硬件如何或者服務(wù)器使用哪種應(yīng)用程序。用戶只關(guān)心Web頁面的顯示速度。監(jiān)視最終用戶視圖可以讓你知道是否存在公共可視方面的性能問題。如果Web站點太慢，客戶將放棄并離開。不應(yīng)該等待客戶抱怨才發(fā)現(xiàn)站點有問題。

　　系統(tǒng)和應(yīng)用程序健康。第二個監(jiān)視尺度是查看Web站點的內(nèi)部子系統(tǒng)并檢查每個的問題。典型的WAS Web站點有很多子系統(tǒng)，包括Web服務(wù)器、應(yīng)用程序服務(wù)器、數(shù)據(jù)庫、目錄服務(wù)器和防火墻。任何一處都可能成為瓶頸！

在這個階段，你試圖找到有問題的組件并識別受限制的資源。你可能發(fā)現(xiàn)網(wǎng)絡(luò)帶寬、后端連接、數(shù)據(jù)庫的CPU或其它組件，它們中的任何一個都可能是資源的瓶頸。因此，你必須監(jiān)視所有的組件，包括應(yīng)用程序服務(wù)器、數(shù)據(jù)庫、網(wǎng)絡(luò)和路由器。查看關(guān)鍵的因素并與正常的（預(yù)期狀態(tài)）比較。如果找到了偏差，就更精確地調(diào)查這些部分。

系統(tǒng)健康視圖經(jīng)常提供了對受約束資源的認(rèn)識，但是對于識別問題的根本起因不一定是充分的。對于運行在Java虛擬機(jī)（JVM）上的Java 2企業(yè)版（J2EE）應(yīng)用程序代碼來說這種情況很明顯。例如，如果系統(tǒng)健康監(jiān)視發(fā)現(xiàn)運行應(yīng)用程序的服務(wù)器的CPU利用率很高并且某幾個小服務(wù)程序的響應(yīng)時間很長，實際根本的起因可能是應(yīng)用程序中的某個不好的循環(huán)、同步問題或者數(shù)據(jù)庫索引丟失。為了解決這個問題，你必須獲取更多的信息來找出問題。

應(yīng)用程序視圖。第三個監(jiān)視的尺度是查看應(yīng)用程序內(nèi)部來幫助查找困難的應(yīng)用程序問題。在某個快照提供給定實例的所有Java線程活動信息時，應(yīng)用程序視圖可以給你精確顯示某個緩慢的小服務(wù)程序正在做什么的信息。深入查看應(yīng)用程序的內(nèi)部執(zhí)行對于查找困難的性能問題是很重要的。

　　監(jiān)視什么

　　在最終用戶視圖尺度上，監(jiān)視站點的"用戶負(fù)載"、服務(wù)的事務(wù)和用戶經(jīng)歷的響應(yīng)時間。這些都是相同的基本監(jiān)視數(shù)據(jù)點，你能在預(yù)生產(chǎn)性能和壓力測試中捕捉到這些信息。

　　監(jiān)視最終用戶視圖使你能追蹤Web站點的響應(yīng)時間是否在增加，請求是否在增加以及增加的速度，增加是否是正常的、預(yù)期的狀態(tài)。監(jiān)視的三個主要因素是：

　　1、負(fù)載（并行用戶的數(shù)量）

　　2、響應(yīng)時間

　　3、輸出（每秒鐘的請求數(shù)量）

　　圖1：負(fù)載、響應(yīng)時間和輸出之間的預(yù)期關(guān)系

圖1顯示了這些規(guī)格之間的預(yù)期關(guān)系。A部分是輕負(fù)載區(qū)，顯示隨著并行用戶請求的增加，輸出幾乎直線增長。在某個點開始出現(xiàn)擁擠并且輸出增長率很慢，一直達(dá)到某個飽和點，這個階段稱為輸出平穩(wěn)段，它表現(xiàn)了輸出值的上邊界。其最大值由瓶頸決定--典型的情況是Web站點上飽和的資源。B部分是重負(fù)載區(qū)，隨著客戶端請求的增加，輸出相對不變，但是用戶載入的響應(yīng)時間相應(yīng)地增長。如果請求的數(shù)量加倍，響應(yīng)時間也會加倍。C部分是波浪區(qū)，在某個點一個系統(tǒng)組件被耗盡。此時，輸出開始降低和響應(yīng)時間增加的速度比直線還要快。

通過檢測用戶請求的數(shù)量、輸出和響應(yīng)時間，你能夠知道站點顯示的正常響應(yīng)時間是否根據(jù)請求的容量而增加，或者必須仔細(xì)研究響應(yīng)時間問題。例如，大量的并行客戶端載入的測試結(jié)果顯示當(dāng)并行用戶翻倍（從10個增加到20個）時，平均響應(yīng)時間也翻倍（從150毫秒到301毫秒）了（圖2所示）。如果你監(jiān)視到響應(yīng)時間和用戶請求都翻倍了，應(yīng)該是站點的正常狀態(tài)。監(jiān)視器顯示你有更多的負(fù)載，因此響應(yīng)時間相應(yīng)長一些。在實際運行前有效的性能測試和能力計劃能幫助你確定站點的飽和點。

　　圖2：40個客戶端測試的最終用戶響應(yīng)時間

如果站點接收到的增長的負(fù)載超過了計劃估計的容量，考慮使用縮放技術(shù)處理過多的負(fù)載，同時維持響應(yīng)時間不變。但是，如果監(jiān)視顯示響應(yīng)時間翻倍了而請求沒有成比例增加，你就必須使用到第二種監(jiān)視尺度--系統(tǒng)健康，以找到系統(tǒng)中是否有未預(yù)計到的約束，以及在哪兒找到問題所在。

　　檢測響應(yīng)時間問題

系統(tǒng)健康監(jiān)視對于檢測組件層的響應(yīng)時間問題是很關(guān)鍵的。有很多監(jiān)視器可以用于檢測環(huán)境的全面健康狀況、趨勢并幫助解決問題。每個生產(chǎn)站點必須開發(fā)一個監(jiān)視測量并決定對Web站點的每個組件使用哪種關(guān)鍵的監(jiān)視器。

監(jiān)視系統(tǒng)健康使你了解Web站點上所有組件的關(guān)鍵信息，幫助你定位受約束的資源。一旦找到了這些資源，需要進(jìn)一步發(fā)現(xiàn)和解決約束的起因。對于WebSphere應(yīng)用程序，檢查應(yīng)用程序統(tǒng)計表和Web應(yīng)用程序監(jiān)視器、中間件運行時監(jiān)視器和服務(wù)器監(jiān)視器。本文沒有仔細(xì)討論討論所有的監(jiān)視器。

Web應(yīng)用程序監(jiān)視器。 前面我提到，在最終用戶視圖中，并行請求、響應(yīng)時間和輸出是用戶角度的標(biāo)準(zhǔn)。這三個主要的因素對于Web應(yīng)用程序組件（例如Web頁面、小服務(wù)程序、企業(yè)JavaBean）的每個服務(wù)器層來說也適用。查看每一層的響應(yīng)時間和請求數(shù)量能幫助你識別可以在哪兒找到問題。例如，如果應(yīng)用程序服務(wù)器上的響應(yīng)時間和請求數(shù)量顯示正常，你就知道將研究焦點集中于Web服務(wù)器、網(wǎng)絡(luò)和客戶請求與應(yīng)用程序服務(wù)器之間的其他組件。

對于典型的WAS開發(fā)，用戶的請求通過HTTP服務(wù)器傳遞，接著調(diào)用在應(yīng)用程序服務(wù)器上配置的一個小服務(wù)程序。你可以監(jiān)視HTTP服務(wù)器和應(yīng)用程序服務(wù)器上的應(yīng)用程序性能。根據(jù)特定的監(jiān)視工具和使用的HTTP服務(wù)器，你可以監(jiān)視HTTP服務(wù)器的任何一個或所有三個主要因素。

40個客戶端負(fù)載的狀態(tài)快照運行并顯示，在這種特別的刷新間隔中，處理了40個請求。不幸的是，這個特定的Apache監(jiān)視工具沒有提供把計數(shù)器復(fù)位為0的簡單方法，因此總共的訪問（請求）和每秒鐘的請求覆蓋了整個6個小時的服務(wù)器周期，并且沒有與WebSphere監(jiān)視器相應(yīng)的時間間隔。

監(jiān)視器為每個應(yīng)用程序服務(wù)器負(fù)載、響應(yīng)時間和輸出。圖5顯示了一個使用資源分析器（Resource Analyzer）的小服務(wù)程序化監(jiān)視器快照。這個圖表顯示了40個客戶端運行的應(yīng)用程序服務(wù)器因素，顯示在應(yīng)用程序服務(wù)器中并行請求的平均數(shù)量在35到40個之間，平均響應(yīng)時間小于600毫秒。你能使用整個請求計算每秒鐘的請求數(shù)（圖2中與40個客戶端負(fù)載測試相應(yīng)的這些規(guī)格的最終用戶響應(yīng)時間為635毫秒）。

　　圖3：40個客戶端運行的應(yīng)用程序服務(wù)器各因素

　　中間件運行時監(jiān)視器。你可能需要通過監(jiān)視緩沖池的利用請求，監(jiān)視Web站點上流動的請求的健康。圖4顯示了一個典型的查詢網(wǎng)絡(luò)。對于查詢網(wǎng)絡(luò)中的每個緩沖池或容器，你查看利用情況。對于IBM HTTP服務(wù)器，你監(jiān)視當(dāng)前正在處理的請求和空閑服務(wù)器。

　　圖4：WebSphere查詢網(wǎng)絡(luò)

　　你也能監(jiān)視Web容器的線程池--對象請求代理程序（Object Request Broker，ORB）和數(shù)據(jù)庫連接池。如果任何一個緩沖池達(dá)到了最大的容量，它就可能阻塞了業(yè)務(wù)流。通常，較大對于性能不一定更好，因為額外的容量浪費了資源。因此，隊列和緩沖池的適當(dāng)協(xié)調(diào)對于最佳性能是很重要的。

　　圖5：Web容器線程池監(jiān)視器

　　圖5顯示了Web容器線程池的快照，它的默認(rèn)線程池設(shè)置為最小25，最大50。如果你運行40個客戶端負(fù)載，線程池建立的補充線程高于最小的25個，平均運行38個線程。該緩沖池永遠(yuǎn)不會達(dá)到最大容量50。一旦線程建立了，它們中的大多數(shù)就在使用中，結(jié)果很少線程被消除。這個圖表顯示了Web容器線程池的較好的情況。

　　圖6：較差的動態(tài)線程池示例

　　相反，圖6（它是故意做的）顯示了效率低下的Web容器池。在這個例子中，40個客戶端負(fù)載運行在線程池設(shè)置為最小、最大都是2個線程的Web容器上運行。此外，我選擇了當(dāng)緩沖池超過最大容量時增加。你可以看到，緩沖池大多數(shù)時間運行在最大容量上。因為在超過最大容量時我允許緩沖池增長，建立和消滅數(shù)以百計的容器線程使系統(tǒng)失效了。

　　對于所有的WebSphere線程和連接池，高百分比的最大值顯示特定緩沖池可能引起瓶頸。你能使用另外的監(jiān)視器（例如緩沖池尺寸）和活動線程來幫助協(xié)調(diào)緩沖池。

　　服務(wù)器監(jiān)視器。中間件和Web應(yīng)用程序在下層服務(wù)器上執(zhí)行。你必須查看所有服務(wù)器（包括Web服務(wù)器、應(yīng)用程序服務(wù)器和數(shù)據(jù)庫服務(wù)器）的系統(tǒng)監(jiān)視器--CPU利用率、I/O和分頁。

　　應(yīng)用程序視圖：Java應(yīng)用程序

　　當(dāng)引起性能問題的原因在Java應(yīng)用程序中的時候，你必須能夠監(jiān)視在JVM中執(zhí)行的應(yīng)用程序內(nèi)部發(fā)生了什么事情以識別有問題的源。典型的應(yīng)用程序視圖層次的監(jiān)視需要大量的J2EE編碼和具體應(yīng)用程序的相關(guān)知識。解決表面上是負(fù)載問題的Java應(yīng)用程序問題可能需要這個層次的監(jiān)視。你可以從兩個角度分析運行在WebSphere上的應(yīng)用程序：（1）應(yīng)用程序調(diào)用流和響應(yīng)時間情況，（2）線程狀態(tài)執(zhí)行情況。

　　從應(yīng)用程序調(diào)用流角度看，你需要查找消耗最大響應(yīng)時間的應(yīng)用程序部分。調(diào)用流可能顯示某個小服務(wù)程序作了多重EJB調(diào)用，而每一個EJB調(diào)用作了多重JDBC調(diào)用。分析調(diào)用流使你識別了應(yīng)用程序消耗最多時間的部分。圖7顯示了HitCount應(yīng)用程序調(diào)用流的一部分。這個例子顯示，JDBC響應(yīng)時間大約為1毫秒--是整個響應(yīng)時間中很小一部分，顯示JDBC調(diào)用不是性能問題。

HitCount Servlet Service method (24 ms) ->
                        Inc Bean Increment method  (22 ms) ->
                        DBPreparedStmt executeUpdate (1.28 ms)
                        DBPreparedStmt executeQuery   (1.04 ms)

　　　　示例應(yīng)用程序調(diào)用流

　　作為分析應(yīng)用程序調(diào)用流的補充，你可以檢查JVM中的每個線程的狀態(tài)。線程狀態(tài)執(zhí)行情況監(jiān)視某個時間應(yīng)用程序內(nèi)的每個線程的行動。通過查看線程棧中的結(jié)構(gòu)，可以識別并行瓶頸。例如，我修改了HitCount小服務(wù)程序來調(diào)用緩慢的同步日志程序（通常的問題）。在運行修改過的HitCount時，執(zhí)行了線程轉(zhuǎn)儲。運行50個線程時，39個是棧頂部結(jié)構(gòu)，9個在等待來自Web服務(wù)器的工作。線程棧信息使你能與Web應(yīng)用程序程序員一起排除可伸縮性瓶頸。

　　接口和加工

　　大多數(shù)操作系統(tǒng)和應(yīng)用程序包含了接口以獲得關(guān)鍵的性能指示并為監(jiān)視性能提供基礎(chǔ)的工具。此外某些行業(yè)方案有具體產(chǎn)品的性能接口以提供端對端性能監(jiān)視方案或者專業(yè)的監(jiān)視方案。

　　WAS運行是允許輕量級的、關(guān)鍵的運行時和Web應(yīng)用程序性能因素的服務(wù)器端性能數(shù)據(jù)集合。WAS的一部分--性能監(jiān)視基礎(chǔ)結(jié)構(gòu)（PMI），支持多種客戶端檢索選擇，包括Java和HTTP/XML接口。

　　維持最佳的性能

　　性能監(jiān)視對于Web站點的成功是很關(guān)鍵的。了解每個監(jiān)視尺度的角色將幫助你在性能問題反面影響Web站點前識別、定位和解決它們。有了WebSphere API和支持工具，你能監(jiān)視每個尺度來確保Web站點的性能最佳