幫助您了解監視和度量 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 格式的信息。
圖 1. 門戶內部緩存清單 Portlet 的示例圖像
設置適當的緩存大小和生存期值對於實現最佳性能非常關鍵：
如果某個特定的緩存太小，則 WebSphere Portal 服務器會太頻繁地訪問數據庫，從而導致性能下降。
如果緩存太大，則會浪費 JVM 中的內存，並且可能導致內存不足條件或增加內存分頁，這兩種情況都會導致性能下降。
太頻繁過期的緩存會導致不必要的性能下降；因此，優化緩存生存期值也是非常重要的。
此外，務必記住在 WebSphere Portal 版本之間升級時，門戶緩存行為會更改，從而導致性能更改。在調查性能的任何時候檢查緩存非常重要，而內部門戶緩存清單 Portlet 恰好可以完成此工作。
在優化緩存大小和性能時，務必將此 Portlet 提供的數據與 WebSphere Portal 性能調優指南結合使用。此方法可以幫助您為特定的環境和工作負載設定最佳值。
動態緩存
WebSphere Application Server 緩存監視器也是非常有用的工具，可幫助您監視應用程序。對於已配置進行緩存的 Portlet，該工具可以向您顯示：
您獲得的緩存命中率和未命中率是多少
緩存的裝滿情況如何
使用 LRU（最近較少使用）算法從緩存中逐出的條目有多少
Servlet 緩存是否已啟用
圖 2 演示了該工具提供的信息。
圖 2. 動態緩存統計信息屏幕示例
正如您應該知道的那樣，在 WebSphere Application Server 上啟用 Servlet 緩存以後，可以對 Portlet 的輸出進行緩存。在許多情況下，緩存是禁用的，或者沒有對 Portlet 本身進行配置以利用緩存。有關如何配置 Portlet 以進行緩存的信息超出了本文的范圍，但是有一些有用的參考資料可以提供幫助。務必記住，緩存對某些 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結合使用，您無需編寫任何自定義代碼即可查看性能監視接口（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. 新的節
<LocationMatch "cloneID$" >
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]
</LocationMatch>
此節在添加到所有的 IHS 服務器以後，將允許您獲得與特定副本的會話關聯。例如，要使用此節，您將訪問門戶應用程序，並將 ?cloneID=WebSphere_Portal_Clone_2 追加到 URL，您的請求將發送到 WebSphere_Portal_Clone_2。
在大規模環境中，您擁有許多副本，您需要調試或重現某個問題，並且不希望將每個服務器上的每個副本仔細搜尋一遍以確定請求的去向，在這種情況下，上述方法將非常有用。當您查找特定於副本的問題，或者希望基於日志時間戳測量組件發生的性能問題次數時，它也是個理想的工具。
日志記錄和調試
門戶和 WebSphere 日志記錄
您可以在屬性文件 <WP Root>/shared/app/config/log.properties 中或者通過使用 WebSphere Application Server 管理控制台中的 Troubleshooting - Logs and Trace - <Application Server Name> - 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 可以簡化故障排除和開發工作。請按照以下步驟操作：
要安裝該 Servlet，請首先從 Apache Sandbox獲得源代碼 (ConfigurationServlet.java)。
編譯該代碼並將類文件放在 <WP root>/shared/app/org/apache/log4j/servlet/ConfigurationServlet.class 中。
編輯位於 <WAS Root>/config/cells/<cellname>/applications/wps.ear/deployments/wps/wps.ear/WEB-INF/web.xml 的 web.xml 文件。
將清單 2 所示的代碼添加到您的 Servlet 列表的末尾：
清單 2. 用於 Servlet 列表的代碼
<servlet>
<servlet-name>log4j</servlet-name>
<display-name>Log4j configuration Servlet</display-name>
<servlet-class>org.apache.log4j.servlet.ConfigurationServlet</servlet-class>
</servlet>
將清單 3 所示的代碼添加到您的 Servlet 映射列表的末尾：
清單 3. 用於 Servlet 映射列表的代碼
<servlet-mapping id="log4j-Config">
<servlet-name>log4j</servlet-name>
<url-pattern>/log4j/*</url-pattern>
</servlet-mapping>
重新啟動服務器以後，您可以快速加載 Log4J 配置，並使用基本上下文的 URI 動態設置日志記錄級別：
http://<hostname>/wps/log4j
圖 8 顯示了該界面：
圖 8. 動態地設置日志記錄的 Log4J
注意：如果您在使用集群環境，您可以修改源代碼以適用於多個副本，因此此版本僅支持一個副本。
自定義頁面監視
為了確定頁面加載緩慢的原因，特別是在問題零星出現的時候，在生成的 HTML 源代碼中添加調試計時信息可能非常有用。這些計時可以針對：
各個 Portlet
全體 Portlet
Servlet 篩選器
刊頭
左導航區
自定義應用程序進程
實現自定義頁面監視以獲得性能數據並非始終是必需的。通常，WebSphere Portal 中的性能監視基礎結構提供了所需的數據。例如，僅只是在 Web 應用程序級別使用 PMI 就可以監視會話數量和請求中所花的時間。
但是，對於自定義監視，我們的策略是將計時信息作為 HTML 注釋輸出，這樣就只有通過查看源代碼才能看到注釋。如果不是在生產環境中執行監視，則可以在頁面上將計時信息顯示為 HTML 的一部分。您可以看到，這個策略是在不引入顯著性能開銷的情況下監視環境（甚至是生產環境）的有效方法。
添加此計時信息的最容易方法是修改主題 JSP。如果沒有自定義的 WebSphere Portal 主題，您可以在以下位置找到現有的主題 JSP：
/WebSphere/AppServer/installedApps/<clone>/wps.ear/wps.war/themes
例如，要添加調試計時信息，您可以使用以下行更新主題的 Default.jsp 文件開頭的內容：
<% long start = java.lang.System.currentTimeMillis(); %>
此更新將初始化用於呈現頁面的開始時間。要輸出此時間點之後的呈現時間，可以在 JSP 的結尾使用以下行：
<!-- TOTAL TIME: <%= java.lang.System.currentTimeMillis() - start %>ms -->
其基本思想是在所呈現頁面的關鍵區域周圍放置類似於此調試信息的代碼。然後，在呈現頁面時，您可以通過查看 HTML 源代碼確定呈現每個關鍵區域所花的時間。取決於您希望測量的具體細目，可能必須在某個時間點重置 start 變量的值。例如，您可能希望測量呈現左導航區或刊頭鏈接所花的時間。如果您有正在運行的自定義應用程序，則可以在這些呈現階段中調用您的自定義代碼。
要以這種方式實現對各個 Portlet 的計時，您首先需要找到主題的 Default.jsp 中呈現該內容空間的部分，並緊跟在該部分之前重置計時器。在此例中，我們還在頁面上輸出了呈現所有 Portlet 所花的總時間，如清單 4 所示：
清單 4. 所花的總呈現時間
<% start = java.lang.System.currentTimeMillis(); %>
<!--<CONTENTSPACE>--> <wps:screenRender />
<!--</CONTENTSPACE>-->
<!-- PORTLET TOTAL TIME:
<%= java.lang.System.currentTimeMillis() - start %>ms -->
然後（這裡是訣竅），您需要編輯位於以下位置的 WebSphere Portal 服務器的 UnlayeredContainer-H.jsp 文件：
/WebSphere/AppServer/installedApps/<clone>/wps.ear/wps.war/skins
編輯緊跟在 model.render(child) 調用之前或之後的某個地方；在迭代遍歷該模型的位置，您需要添加以下行：
之前：
<% start = java.lang.System.currentTimeMillis(); %>
之後
<!-- PORTLET TIME: <%= java.lang.System.currentTimeMillis() - start %> -->
清單 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();
%>
<td valign="top" <% String width =
(String)childMetrics.getValue(childMetrics.WIDTH);
if (width != null)
{
out.print ("width=\"");
out.print (width);
out.print ("\"");
} %>>
<% model.render (child); >
</td>
<!-- PORTLET TIME: <%= java.lang.System.currentTimeMillis() - start %> -->
<% } %>
在該處放置此代碼的作用在於，對於頁面上呈現的每個 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: <%= (((Long)request.getAttribute("servletEndTime")).longValue() - ((Long)request.getAttribute("servletStartTime")).longValue()) %>ms -->
說明：對於上面的示例，必須在應用程序中添加自定義代碼，從而為所測量的組件添加適當的開始和結束時間，在此例中為 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 是個非常有用的工具。它可以提供有用的信息，包括分析實時請求、查看趨勢和幫助查找應用程序中的問題。
結束語
要有效地解決與 Websphere Portal 相關的性能問題，對環境進行良好的監視和測量是非常重要的。擁有 WebSphere Portal 環境的准確視圖可以幫助您了解問題及其根源。
