監視WebSphere Portal 環境中的效能

要優化 WebSphere Portal 環境以實現最佳效能，您需要知道哪些方面需要優化。本文討論的監視方法涵蓋 WebSphere Portal 的幾個重要方面。它們可以幫助您檢視 WebSphere Portal 環境的真實行為，並最終確定瓶頸和潛在問題。本文旨在概述監視方法，而不是深入研究任何特定的方法。本文為大多數負責解決此類問題的人員提供了一個很好的起點。我們的目標是向您介紹足夠多的方法，以便您能夠以及時、經濟合算的方式解決效能問題。

說明： 參考資料部分包括了可在效能優化過程中提供幫助的若干連結。

本文討論以下有關效能監視的主題：

• 快取
• JVM 監視
• 資料庫分析
• 叢集
• 日誌記錄和除錯
• 自定義頁面監視
• IBM Tivoli® Composite Application Manager (ITCAM)

快取

在本部分中，我們重點討論門戶內部快取和動態快取 (Dynacache)。

內部門戶快取

WebSphere Portal 是一個非常複雜的應用程式，通過 WebSphere Application Server 廣泛使用了快取。為您的特定環境優化這些快取對於實現效能良好的門戶至關重要。對於標準安裝，要監視這些快取並不容易，並且在許多時候，您將依賴於啟用適當級別的日誌記錄才能確定特定快取的使用情況。這是一種非常低效的方法，可能非常耗時和棘手。但是，一個稱為“內部門戶快取清單”的 Portlet 允許您監視內部門戶快取，並檢視重要的快取統計資訊，其中包括：

• 每個快取的當前快取條目計數
• 每個快取的最高快取條目數量計數
• 每個快取的配置大小。

圖 1 顯示了該 Portlet 提供的 csv 格式的資訊。

設定適當的快取大小和生存期值對於實現最佳效能非常關鍵：

• 如果某個特定的快取太小，則 WebSphere Portal 伺服器會太頻繁地訪問資料庫，從而導致效能下降。
• 如果快取太大，則會浪費 JVM 中的記憶體，並且可能導致記憶體不足條件或增加記憶體分頁，這兩種情況都會導致效能下降。
• 太頻繁過期的快取會導致不必要的效能下降；因此，優化快取生存期值也是非常重要的。

此外，務必記住在 WebSphere Portal 版本之間升級時，門戶快取行為會更改，從而導致效能更改。在調查效能的任何時候檢查快取非常重要，而內部門戶快取清單 Portlet 恰好可以完成此工作。

在優化快取大小和效能時，務必將此 Portlet 提供的資料與 WebSphere Portal 效能調優指南（請參閱參考資料）結合使用。此方法可以幫助您為特定的環境和工作負載設定最佳值。

動態快取

WebSphere Application Server 快取監視器也是非常有用的工具，可幫助您監視應用程式。對於已配置進行快取的 Portlet，該工具可以向您顯示：

• 您獲得的快取命中率和未命中率是多少
• 快取的裝滿情況如何
• 使用 LRU（最近較少使用）演算法從快取中逐出的條目有多少
• Servlet 快取是否已啟用

圖 2 演示了該工具提供的資訊。

正如您應該知道的那樣，在 WebSphere Application Server 上啟用 Servlet 快取以後，可以對 Portlet 的輸出進行快取。在許多情況下，快取是禁用的，或者沒有對 Portlet 本身進行配置以利用快取。有關如何配置 Portlet 以進行快取的資訊超出了本文的範圍，但是有一些有用的參考資料可以提供幫助（請參閱參考資料中的“快取 Portlet 輸出”和“使用 WebSphere Portal V5.1 開發包含靜態內容和動態內容的高效能網站”）。務必記住，快取對某些 Portlet 來說是不適宜的，在使用個性化的時候尤其是如此。對於其內容在使用者之間共享的 Portlet，快取可以顯著改進總體效能。

JVM 監視

與任何 Java™ 2 Platofrm, Enterprise Edition 應用程式伺服器一樣，Java 虛擬機器 (JVM) 是負責大部分處理工作的關鍵元件。在 WebSphere Portal 環境中，呈現的每個頁面均由 JVM 處理。JVM 具有各種元件，每個元件對 WebSphere Portal 站點的總體效能具有不同的影響。監視諸如堆、Servlet 執行緒和資料庫連線池等頂級元件，可以瞭解 JVM 處理請求時所發生的情況。這還可以提供潛在瓶頸位置指示。

使用 WebSphere 效能監視基礎結構（請參閱參考資料），您可以從各個 WebSphere Application Server 元件和主要的 JVM 組成部分收集效能資料。通過將此基礎結構與 IBM Tivoli Performance Viewer（這是一個顯示和監視效能資料的 Java 客戶端，請參閱參考資料）結合使用，您無需編寫任何自定義程式碼即可檢視效能監視介面（performance monitoring interface，PMI）資料。Tivoli Performance Viewer 還包括一個顧問程式，可以基於效能資料提供優化更改建議。

當然，您可以使用 WebSphere 提供的 Java Management Extensions (JMX) API（請參閱參考資料）編寫自定義監視程式碼。第一步是啟用效能監視服務，並將規範級別設定得較低。有關如何啟用 PMI 服務的詳細資訊，請參考 WebSphere 技術文件庫（請參閱參考資料）。通過使用 JMX，您可以輕鬆編寫 Java 程式碼來自動輪詢應用程式伺服器度量，並記錄資料以便分析。所收集的資料可以儲存在逗號分隔值（comma-separated value，CSV）檔案中，然後可以將該檔案匯入大多數圖表繪製工具，例如 Microsoft® Excel 和 OpenOffice。通過為資料繪製圖表，您可以輕鬆確定趨勢和模式。

WebSphere 技術文件庫中還顯示了用於建立管理客戶端和獲取 PMI 值的示例程式碼。您還可以參閱 developerWorks® 文章“使用 WebSphere Application Server 的 Performance Monitoring Infrastructure API 編寫效能監控工具”。由於本文的範圍所限，這裡就不包括示例程式碼了。

某些值得提及的度量包括 Java Database Connectivity (JDBC)、JVM 記憶體使用、Servlet 傳輸執行緒和資料庫連線。當與 IBM HTTP Server 執行緒統計資料結合使用時，此級別的監視可以成為了解託管環境的強有力方法。

圖 3 顯示的 WebSphere Portal 環境包括五個節點，每個節點有兩個應用程式伺服器。

圖 3. JVM 監視示例
 

資料庫分析

資料庫是您在考慮效能相關問題時應該檢查的另一個重要方面。WebSphere Portal 廣泛使用了資料庫來儲存資訊。明確地說，應該監視以下資料庫並按如下順序優化它們以實現最佳效能：

• 門戶資料庫
• LDAP 資料庫
• 特定於應用程式的資料庫

如果其中任何資料庫執行 IBM DB2®，則您將擁有一些可用於幫助監視和優化資料庫效能的選項。DB2 資料庫系統監視的兩個基本策略如下：

• 快照監視。允許您捕獲特定時間點的資料庫狀態。
• 事件監視。允許您在事件發生時捕獲和記錄事件。

兩種監視的結果儲存在監視元素中。下面是可用的監視元素的列表：

• 計數器。顯示某個事件發生的總次數。
• 量規。指示某個項的當前值。
• 水位。指示某個項曾達到的最大和最小值。
• 資訊元素。顯示參考詳細資訊。
• 時間戳。指示某個活動的發生日期和時間。
• 時間元素。顯示執行某個活動所花的時間長度。

有關 DB2 資料庫系統監視的更多詳細資訊可以在以下文章中找到：“Performance Monitoring, Part 1:It's a Snap(shot)”和“Performance Monitoring, Part 2”。

如果您是在 z/OS® 上執行 DB2，您應該下載 DB2 Performance Monitor for z/OS systems（請參閱參考資料）。此監視器是用於確定長時間執行的 SQL 語句、鎖定衝突和儲存消耗的極好資產。

您應該監視正常活動過程中的資料庫連線。瞭解連線工作負載非常重要，以便能夠正確地優化 WebSphere Application Server 中的連線池設定。圖 4 顯示了從某個監視資料庫連線的自定義工具中捕獲的螢幕快照。務必記住，您不必編寫某個自定義工具；這裡進行自定義是為了讓無法直接訪問生產系統的開發人員更容易完成監視過程。

圖 4. 監視各個資料庫的資料庫連線
 

叢集

跟蹤大規模環境中的問題可能令人畏懼。在僅僅一個副本上重現問題通常非常困難。WebSphere 中的工作負載管理器（Workload Manager，WLM）執行負載平衡，並且可以將流量定向到叢集或單元中為應用程式定義的任何可用副本。您可以通過為 WebSphere Application Server 定義的 WebSphere 埠直接訪問到某個副本，但是在大多數環境中，這會受到防火牆的阻止。為了繞過防火牆的阻止，您可以使用 IBM HTTP Server (IHS) (Apache) 規則，基於 URL 查詢字串將流量定向到某個副本。

為此，要做的第一件事情是確定副本的名稱。您可以使用在 WebSphere Application Server 管理控制檯中指定的名稱。您還需要知道用於提供副本的埠。請參見圖 5。

圖 5. WebSphere Application Server 管理控制檯

擁有此資訊之後，您可以使用新的節來編輯 IHS (Apache) conf 檔案。通常可以通過執行 ps -ef|grep http 並確定正在使用的 conf 檔案來找到 http.conf 檔案。如果您的環境是新的，請參考安裝說明。對於此示例，關鍵字為 cloneID，CloneName 為 WebSphere_Portal 和 WebSphere_Portal_Clone_2，埠分別為 9085/9086。目標 WebSphere Application Server 主機名稱為主機 name.ibm.com。請參見清單 1。

清單 1. 新的節

RewriteEngine on
RewriteCond %{QUERY_STRING} ^WebSphere_Portal_Clone_2
RewriteRule /(.*)/cloneID$ http://hostname.ibm.com:9086/$1 [P]

RewriteCond %{QUERY_STRING} ^WebSphere_Portal
RewriteRule /(.*)/cloneID$ http://hostname.ibm.com:9085/$1 [P]

	

此節在新增到所有的 IHS 伺服器以後，將允許您獲得與特定副本的會話關聯。例如，要使用此節，您將訪問門戶應用程式，並將 ?cloneID=WebSphere_Portal_Clone_2 追加到 URL，您的請求將傳送到 WebSphere_Portal_Clone_2。

在大規模環境中，您擁有許多副本，您需要除錯或重現某個問題，並且不希望將每個伺服器上的每個副本仔細搜尋一遍以確定請求的去向，在這種情況下，上述方法將非常有用。當您查詢特定於副本的問題，或者希望基於日誌時間戳測量元件發生的效能問題次數時，它也是個理想的工具。

日誌記錄和除錯

門戶和 WebSphere 日誌記錄

您可以在屬性檔案 /shared/app/config/log.properties 中或者通過使用 WebSphere Application Server 管理控制檯中的 Troubleshooting - Logs and Trace - - Diagnostic Trace Service 選項啟用不同 Websphere Portal 元件的除錯日誌記錄。要在控制檯中啟用除錯日誌記錄，請選擇 Enable Trace，然後提供 traceString 名稱/值對，以啟用特定元件的除錯日誌記錄。請確保指定輸出檔名稱，然後單擊 Apply。跟蹤檔案可能很快變得非常大，因此要確保您指定的位置足以儲存該輸出。

圖 6 顯示了控制檯設定。

圖 6. 使用控制檯設定門戶日誌記錄

例如，以下兩種型別的 traceString 可能非常有用：

• WMM。啟用 WebSphere 成員管理器（WebSphere member manager，WMM）使您可以檢查對外部成員資格儲存庫（通常是某個 LDAP 伺服器）的呼叫。您可以使用這種型別來確定大型結果或組中的組。
  
  traceString=com.ibm.websphere.wmm.*=all=enabled:com.ibm.ws.wmm.*=all=enabled:
  WSMM=all=enabled:com.ibm.ws.security.*=all=enabled
• URL 對映。啟用 URL 對映使您可以對每個頁面/標籤請求所呼叫的 URL 對映數量進行監視和計數。在受控的環境中執行此對映為您提供了優化對映快取限制的很好起點。
  
  traceString=com.ibm.wps.mappingurl.*=all=enabled:
  com.ibm.wps.command.mappingurl.*=all=enabled:com.ibm.wps.engine.*=all=enabled

有關其它 traceString 的更多資訊，請參考 WebSphere Portal 資訊中心的 WebSphere Portal 執行時日誌記錄主題（請參閱參考資料）。您還可以從 WebSphere Portal 管理使用者介面中的 Portal Analysis - Enable Tracing 下面啟用 WebSphere Portal 跟蹤。這些跟蹤會立即應用，並且在重新啟動後不會保留，但是它們對於除錯會非常有用。請參見圖 7。

圖 7. 執行時的門戶跟蹤

特定於應用程式的日誌記錄

如果您的應用程式使用 Log4J（請參閱參考資料），您可以使用一個 Servlet 來動態啟用和禁用 Log4J 日誌記錄級別，而無需重新啟動伺服器。該 Servlet 可以簡化故障排除和開發工作。請按照以下步驟操作：

1. 要安裝該 Servlet，請首先從 Apache Sandbox（請參閱參考資料）獲得原始碼 (ConfigurationServlet.java)。
2. 編譯該程式碼並將類檔案放在 /shared/app/org/apache/log4j/servlet/ConfigurationServlet.class 中。
3. 編輯位於 /config/cells//applications/wps.ear/deployments/wps/wps.ear/WEB-INF/web.xml 的 web.xml 檔案。
4. 將清單 2 所示的程式碼新增到您的 Servlet 列表的末尾：
   
   
   
   清單 2. 用於 Servlet 列表的程式碼
   

   log4j Log4j configuration Servlet org.apache.log4j.servlet.ConfigurationServlet

   
   
5. 將清單 3 所示的程式碼新增到您的 Servlet 對映列表的末尾：
   
   
   清單 3. 用於 Servlet 對映列表的程式碼
   

   log4j /log4j/*

   
   

重新啟動伺服器以後，您可以快速載入 Log4J 配置，並使用基本上下文的 URI 動態設定日誌記錄級別：

http:///wps/log4j

圖 8 顯示了該介面：

圖 8. 動態地設定日誌記錄的 Log4J

注意：如果您在使用叢集環境，您可以修改原始碼以適用於多個副本，因此此版本僅支援一個副本。

自定義頁面監視

為了確定頁面載入緩慢的原因，特別是在問題零星出現的時候，在生成的 HTML 原始碼中新增除錯計時資訊可能非常有用。這些計時可以針對：

• 各個 Portlet
• 全體 Portlet
• Servlet 篩選器
• 刊頭
• 左導航區
• 自定義應用程式程式

實現自定義頁面監視以獲得效能資料並非始終是必需的。通常，WebSphere Portal 中的效能監視基礎結構提供了所需的資料。例如，僅只是在 Web 應用程式級別使用 PMI 就可以監視會話數量和請求中所花的時間。

但是，對於自定義監視，我們的策略是將計時資訊作為 HTML 註釋輸出，這樣就只有通過檢視原始碼才能看到註釋。如果不是在生產環境中執行監視，則可以在頁面上將計時資訊顯示為 HTML 的一部分。您可以看到，這個策略是在不引入顯著效能開銷的情況下監視環境（甚至是生產環境）的有效方法。

新增此計時資訊的最容易方法是修改主題 JSP。如果沒有自定義的 WebSphere Portal 主題，您可以在以下位置找到現有的主題 JSP：
/WebSphere/AppServer/installedApps//wps.ear/wps.war/themes

例如，要新增除錯計時資訊，您可以使用以下行更新主題的 Default.jsp 檔案開頭的內容：

此更新將初始化用於呈現頁面的開始時間。要輸出此時間點之後的呈現時間，可以在 JSP 的結尾使用以下行：

<!-- TOTAL TIME: ms --&gt

其基本思想是在所呈現頁面的關鍵區域周圍放置類似於此除錯資訊的程式碼。然後，在呈現頁面時，您可以通過檢視 HTML 原始碼確定呈現每個關鍵區域所花的時間。取決於您希望測量的具體細目，可能必須在某個時間點重置 start 變數的值。例如，您可能希望測量呈現左導航區或刊頭連結所花的時間。如果您有正在執行的自定義應用程式，則可以在這些呈現階段中呼叫您的自定義程式碼。

要以這種方式實現對各個 Portlet 的計時，您首先需要找到主題的 Default.jsp 中呈現該內容空間的部分，並緊跟在該部分之前重置計時器。在此例中，我們還在頁面上輸出了呈現所有 Portlet 所花的總時間，如清單 4 所示：

清單 4. 所花的總呈現時間

				

<!----&gt  
<!----&gt
<!--  PORTLET TOTAL TIME: 
ms --&gt

然後（這裡是訣竅），您需要編輯位於以下位置的 WebSphere Portal 伺服器的 UnlayeredContainer-H.jsp 檔案：
/WebSphere/AppServer/installedApps//wps.ear/wps.war/skins
編輯緊跟在 model.render(child) 呼叫之前或之後的某個地方；在迭代遍歷該模型的位置，您需要新增以下行：

之前：

之後

<!-- PORTLET TIME: --&gt

清單 5 顯示了更完整的程式碼摘錄。

清單 5. 對 model.render(child) 的呼叫

				
for (Iterator iterator = model.getChildren(currentElement);iterator.hasNext();)
	{
  CompositionNode child = (CompositionNode) iterator.next ();
  CompositionMetrics childMetrics = child.getMetrics();
  start = java.lang.System.currentTimeMillis();
%>

在該處放置此程式碼的作用在於，對於頁面上呈現的每個 Portlet，您在其下放置了 HTML 註釋，用於顯示呈現該 Portlet 所花的毫秒數。請注意，由於 JSP 中的變數範圍，您不是在重置 Default.jsp 中的 start 變數。

注意：這個用於顯示各個 Portlet 的呈現時間的特定策略僅在關閉並行 Portlet 呈現的情況下進行了測試。

以這種方式向 HTML 註釋新增除錯計時資訊的優點是什麼呢？首先，在檢測程式碼中的此資訊之後，與深入搜尋日誌檔案和除錯輸出相比，評估各個元件的計時情況就容易多了，在問題零星出現的情況下尤其是如此。通常，將後端日誌檔案與特定的請求相關聯是非常困難的。使用此方法，每當出現頁面載入緩慢的情況，您就可以（手動或以程式設計方式）檢查 HTML 原始碼，以確定導致延遲的原因，並最終將總體頁面載入時間分攤到各個元件。

此外，使用此方法，很容易編寫使用輪詢和定期頁面載入來探測 WebSphere Portal 頁面的應用程式。可以提取各個元件的計時效能資料並繪製圖表，以及觀察隨時間推移的變化趨勢。此方法可以確定效能趨勢和效能峰值。例如，在一個案例研究中，結果發現特定的 WebSphere Portal 快取定期地提前過期，並在自定義應用程式程式碼中導致效能峰值。在對各個元件繪製圖表之後，很容易確定此問題。

用於編寫自定義工具的 Apache HTTP 客戶端庫

對於希望編寫自定義監視器和圖表繪製工具的開發人員，可以使用開放原始碼的 Jakarta Apache HTTP 客戶端庫（請參閱參考資料）。

該客戶端庫為開發人員提供了一種容易的方法，可用於編寫使用 HTTP 協議的典型瀏覽器互動程式。它支援 Cookie、SSL 和所有 HTTP 命令。為了說明它有多麼容易，清單 6 顯示了對某個 URL 執行 HTTP GET 的程式碼片段：

清單 6. HTTP GET

				
HttpClient client = new HttpClient();
client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
GetMethod getMethod = new GetMethod(url);
getMethod.setFollowRedirects(true);
int statusCode = client.executeMethod(getMethod);
String htmlData = getMethod.getResponseBodyAsString();

使用此方法所能測量的內容是沒有限制的。如果您有在執行的自定義應用程式，您可以測量處理請求的過程中的任何步驟。這些步驟的計時可作為屬性新增到請求物件，然後在 JSP 中使用類似如下的程式碼將結果輸出到 HTML 註釋：

<!-- SERVLET FILTER TIME: ms --&gt

說明：對於上面的示例，必須在應用程式中新增自定義程式碼，從而為所測量的元件新增適當的開始和結束時間，在此例中為 Servlet 篩選器中所花的總時間。

作為此程式碼所能生成的資訊型別的示例，圖 9 顯示了一個自定義應用程式，它輪詢 WebSphere Portal 頁面併為從 HTML 原始碼提取的各個元件的計時資訊繪製圖表。

圖 9. 自定義應用程式計時圖表
 

IBM Tivoli Composite Application Manager

當今的許多應用程式相當複雜，跨越不同的技術和軟體，例如 Web 伺服器、應用程式伺服器、資料庫和後端系統。典型的監視工具非常適合於每個單獨的方面，但是允許您作為整體監視這些組合應用程式的工具卻不多。

Tivoli Composite Application Manager 包括兩個主要元件：管理伺服器和資料收集器。資料收集器駐留在應用程式伺服器上並收集所需資料，而管理伺服器則從所有資料收集器收集所有資訊，並允許您對該資訊進行分析。

Tivoli Composite Application Manager 的部分功能如下：

• 按需監視（Monitoring on demand，MOD）允許設定計劃，以捕獲您懷疑存在問題的時間段中的請求的百分比取樣。然後可以在管理伺服器上使用工具定位和分析較慢的事務。按需監視允許您設定不同級別的監視，從生產模式（基本資料），到問題確定模式，一直到允許您獲得底層詳細資訊的跟蹤模式。
• 動態的請求搜尋允許您分析系統上的實時請求。
• 它允許基於歷史記錄分析和趨勢來分析應用程式的效能。
• 它允許您設定陷阱以檢測和排除問題區域。
• 它提供了記憶體診斷功能以幫助檢測和修復記憶體洩漏。
• 現成提供了報告工具以幫助進行問題分析。

在跨越不同應用程式和子系統的複雜應用程式中，Tivoli Composite Application Manager 是個非常有用的工具。它可以提供有用的資訊，包括分析實時請求、檢視趨勢和幫助查詢應用程式中的問題。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-594332/，如需轉載，請註明出處，否則將追究法律責任。