监视WebSphere Portal 环境中的性能

最新推荐文章于 2024-09-05 11:00:53 发布

cuanfangxiang3803

最新推荐文章于 2024-09-05 11:00:53 发布

阅读量157

点赞数

文章标签： java 数据库后端

要优化 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 输出”和“使用 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 可以简化故障排除和开发工作。请按照以下步骤操作：

要安装该 Servlet，请首先从 Apache Sandbox（请参阅参考资料）获得源代码 (ConfigurationServlet.java)。
编译该代码并将类文件放在 /shared/app/org/apache/log4j/servlet/ConfigurationServlet.class 中。
编辑位于 /config/cells//applications/wps.ear/deployments/wps/wps.ear/WEB-INF/web.xml 的 web.xml 文件。
将清单 2 所示的代码添加到您的 Servlet 列表的末尾：

清单 2. 用于 Servlet 列表的代码
log4jLog4j configuration Servletorg.apache.log4j.servlet.ConfigurationServlet
将清单 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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14789789/viewspace-594332/

cuanfangxiang3803

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
监视WebSphere Portal 环境中的性能

要优化 WebSphere Portal 环境以实现最佳性能，您需要知道哪些方面需要优化。本文讨论的监视方法涵盖 WebSphere Portal 的几个重要方面。它们可以帮助您查看 WebSphere Portal 环境的真实...
复制链接

扫一扫