配置 WebSphere Business Monitor 以实现高吞吐量和高性能

文档选项 未显示需要 JavaScript 的文档选项 英文原文

级别： 中级

Torsten Wilms, IT 咨询专家, IBM

2009 年 10 月 19 日

学习 IBM® WebSphere® Business Monitor 组件的架构、实现和性能调优的最佳实践。本文包含对性能影响最大的 Monitor 组件的基于基准测试的调优指导，以及事件处理和仪表板服务器调优。

简介

本文提供 IBM WebSphere Business Monitor V6.1（以下简称 Monitor）的性能调优指导，讨论开发和配置的最佳实践，基于性能基准度量介绍对吞吐量和响应时间影响最大的 Monitor 组件的调优参数。本文面向的读者为熟悉 Monitor 的 WebSphere 顾问、IT 专家和 IT 架构师。

图 1 展示了 Monitor 环境中的各种组件。本文将介绍图表中包含的以下每个组件：

• 在 WebSphere Integration Developer 中实现高性能模型
• 在 Monitor Toolkit 中实现 Monitor Model 的最佳建模实践
• 调优 Common Event Infrastructure (CEI)
• 调优 Monitor
• 调优 Monitor 数据库
• 调优仪表板

在 WebSphere Integration Developer 中实现高性能模型

Monitor 使用 Java Message Service (JMS) 目标从 Common Event Infrastructure (CEI) 接收 Common Base Events（事件）。从性能角度看，这意味着 JMS 消息将被序列化并反序列化，这很耗费 CPU 资源。而且，JMS 消息将持久存在于消息引擎的数据库。图 2 展示了 Monitor 环境中的一个典型事件流。

为避免不必要的 CPU 和 I/O 占用，您应该只在确实需要进行业务活动监视时才打开 Integration Developer 的事件发送功能，从而限制事件的数量。

高性能建模

本节关注使用 Monitor Toolkit 建模时如何提高性能。

循环等待时间触发器

在 Monitor Toolkit 中，您可以在监视器模型中设置一个循环等待时间触发器（recurring wait-time trigger），如图 4 所示。循环等待时间触发器将执行周期性计算。循环等待时间触发器的值定义计算该触发器的时间间隔。循环等待时间触发器的值取决于您的应用程序设计。但是，为了优化性能，您应该将循环等待时间触发器的值设置为尽可能长的时间间隔，因为短间隔意味着短时间内要进行大量计算，从而导致较高的 Monitor 服务器 CPU 占用。

交付到多个实例

交付到多个实例（Deliver to all instances）（见图 5）是针对多个相关匹配的一个入站事件交付选项。如果您选择这个选项（默认选项是 Treat as error），当您拥有许多活动实例并且一个事件与这些实例中的多数实例相关时，您需要十分小心。例如，假设您有一百万个活动实例。如果一个事件与所有这些实例相关，且每 10 秒到达一次，那么这将导致每秒超过 100,000 个事件交付，从而导致很高的 Monitor 服务器 CPU 占用。

调优 CEI

Monitor 将消费 CEI 交付的 Common Base Events，因此，调优 CEI 是提高 Monitor 性能的一个重要因素。本小节介绍如何配置 Event Group 配置文件并最小化不必要的处理，从而改善性能。

CEI Event Group 配置文件

每个监视器模型在 Common Base Infrastructure (CBI) 服务器上都部署有一个 Event Group 配置文件。默认情况下，Event Group 配置文件有一个事件选择器字符串，其值为 CommonBaseEvent[true()]。图 7 展示了默认 wbm_GlobalHTMM 监视器模型的 Event Group。

到达 CEI 的一个事件被发送到每个 Event Group，针对每个 Event Group，对应的事件选择器字符串被计算为 true。如果 n 个监视器模型将事件选择器字符串设置为 true，则一个事件将被发送 n 次。为避免将每个事件发送到所有监视器模型，您应使用一个更具体的事件选择器字符串。

这里展示的默认选择器转发来自 CBI 监视器模型的所有事件发起者提交的所有事件：

CommonBaseEvent[true()] 

但是，以下选择器只转发一个带有模板 myBusinessProcess 的 Business Process Execution Language (BPEL) 流程提交的事件：

CommonBaseEvent[(extendedDataElements[@name = 
                        'processTemplateName']/values = 'myBusinessProcess')]

按照以下操作编辑 Integrated Solutions Console 中的一个事件组的事件选择器字符串：

1. 选择 Service Integration => Common Event Infrastructure => Event Services。
2. 选择 Default Common Event Infrastructure event server。
3. 选择 Event Groups。
4. 选择要修改的 Event Group。
5. 修改 Event Selector String 字段的值。
6. 单击 OK，然后单击 Save。

All events 事件组

默认情况下，All events 事件组在 CBI 安装过程中创建。这个事件组将所有事件分发到一个默认的 JMS 目标。这种事件分发并不是 Business Monitor 必需的，因此您应该删除它以避免这个额外的分发。

按照以下操作在 Integrated Solutions Console 中删除 All events 事件组：

1. 选择 Service Integration => Common Event Infrastructure => Event Services。
2. 选择 Default Common Event Infrastructure event server。
3. 选择 Event Groups。
4. 选择 All events，如图 8 所示。
5. 单击 Delete。
6. 单击 OK，然后单击 Save。

禁用 CBI 事件验证

默认情况下，CBI 将验证事件的语义，但这种事件验证占用大量 CPU 资源，只应该在绝对需要时使用。如果您使用的是 WebSphere Process Server 或另一个可信的 Common Base Event 发送器，这种验证并不需要。要禁用事件验证，在发送器配置文件中设置一个新的自定义属性 validateEvent，并将它的值设置为布尔值 false。

按照以下操作在 Integrated Solutions Console 中添加一个自定义属性 validateEvent：

1. 选择 Service Integration => Common Event Infrastructure => Event emitter factories。
2. 选择 Default Common Event Infrastructure event emitter。
3. 选择 Custom Properties。
4. 单击 New。
5. 在 Properties 对话框（如图 9 所示）中，将这个新的自定义属性命名为 validateEvent，并将其值指定为 false。
6. 选择 java.lang.Boolean 作为 Type。
7. 单击 OK，然后单击 Save。

禁用 CBI 事件数据存储

默认情况下，CBI 将事件分发到 JMS 目标和一个事件数据存储。将事件存储在数据存储中是一种消耗大量 I/O 资源的操作，Monitor 不需要该操作。为提高性能，您应该禁用事件数据存储。如果需要，您可以随时打开该功能以进行调试和测试。

按照以下操作在 Integrated Solutions Console 中禁用事件数据存储：

1. 选择 Service Integration => Common Event Infrastructure => Event Services。
2. 选择 Default Common Event Infrastructure event server。
3. 取消选中 Enable event data store，如图 10 所示。
4. 单击 OK，然后单击 Save。

调优 Monitor

本小节讨论调优 Monitor 服务器的参数。

针对 Monitor 的重要调优参数有 Message consumption batch size、Event processing batch size 和 recurring wait-time checking intervals，如图 12 所示。

Message consumption batch size

message consumption batch size 参数定义了监视器模型针对单个事务从其 JMS 输入目标中一次性读入的事件数量。事件存储在 JMS 消息中。当 JMS 消息被监视器模型读取时，它就被反序列化并进入内存。反序列化是 CPU 密集型操作，因此 message consumption batch size 默认设置为 100，即每个监视器模型线程每次读取 100 条 JMS 消息。可以根据进来的 JMS 消息的数量修改批大小以提高吞吐量。折衷办法是，如果批处理中某条 JMS 消息处理失败，就回滚整个事务。如果您观察到 JMS 输入目标中的 JMS 消息数量在增长，这说明 Monitor 来不及处理进入的 JMS 消息。原因可能是 message consumption batch size 设置得太小。

要修改 message consumption batch size，在 Integrated Solutions Console 中执行以下步骤：

1. 选择 Monitor Models。
2. 选择要编辑的监视器模型的版本。
3. 单击 Change Runtime Configuration。
4. 在 Message Consumption 部分（见图 13），在 Batch size 字段中指定一个新值。
5. 单击 OK，然后单击 Save。

如果您修改 message consumption batch size，还要检查每个监视器模型的 De-serialization Work Manager 的 work request queue size 的值。work request queue size 参数指定工作请求队列的大小，这是一个容纳计划内工作对象的缓冲。将 work request queue size 的值设置为等于监视器模型的 message consumption batch size 或设置为空。

在 Integrated Solutions Console 中，按照以下步骤设置 work request queue size：

1. 选择 Resources => Asynchronous beans => Work managers。
2. 选择 wbm_modelname_version_Deserializer，其中 modelname_version 是要配置的监视器模型的版本，如图 14 所示：
3. 在 Work request queue size 字段输入您为该监视器模型的 message consumption batch size 指定的值。
4. 单击 OK，然后单击 Save。

Event processing batch size

来自队列的事件被消费后，它们被放置进一个容纳区域中，并在那里构建一组相关事件。Monitor 等待事件到达以重新排序。延迟时间基于 Late arrival stand off delay 参数。默认延迟时间是 10 秒。图 15 展示了一个 5 秒的延迟。

经过特定的延迟后，事件被放入第二个容纳区域，以构建一个工作单元。该单元被视为准备好进行处理，无论是满足 “Last in stand off delay”，“First in stand off delay” 还是 “Event processing batch size”（见图 16）。

• First in time 根据工作单元创建的时间计算。
• Last in time 根据最近事件添加到工作单元的时间计算。
• Event processing batch size 是工作单元中的事件数量。

一个单元就绪后就会立即被处理。每个事务处理的最大事件数基于 event processing batch size。如果单元中的所有事件不能在一个事务中处理，将使用更多事务，直到单元为空。注意，如果您将基准（stand off）延迟设置为很大的值，您可能会等待很长的一段时间。

Recurring wait-time checking interval

这个参数告知监视器模型检查是否需要发送循环等待时间触发器的频率。该参数应该基于您的监视器模型中的循环等待时间触发器的最大公因数设置。

例如，如果某些触发器定义为每 10 分钟计算一次，而另一些触发器定义为每 15 分钟计算一次，那么应该选择 5 分钟作为循环等待时间检查间隔。选择 10 分钟将意味着 15 分钟间隔触发器可能不能按时计算。为了防止错过触发器计算，默认设置是每分钟执行一次检查。

但是，如果您确信增加这个设置不会损害您的循环等待时间触发器，那么您可以这样做，以便稍微改进常规事件处理吞吐量，因为处理过程不必过于频繁地中断以执行这种检查。

执行以下步骤，在 Integrated Solutions Console 中设置循环等待时间检查间隔：

1. 选择 Monitor Models。
2. 选择要编辑的监视器模型的版本。
3. 选择 Change Runtime Configuration。
4. 在 Message Consumption 部分，更改 Recurring wait-time checking interval 字段的值，如图 17 所示。
5. 单击 OK，然后单击 Save。

调优 JMS

Monitor JMS 目标在监视器模型部署期间创建。这些目标用于接收来自 CEI 的事件。您应该将队列连接工厂的连接池大小和激活规范的 maxConcurrency 参数提高到适当的值。Tivoli® Performance Viewer 能够帮助您确定优化的值。并发性不足和连接池大小不足的一个症状是 CPU 闲置。

调优 Monitor 数据库

要优化 Monitor 性能，您通常需要配置 Monitor 和消息引擎数据库。要理解 Monitor 的数据库调优，需要首先从数据库角度理解 Monitor 应用程序的特征。Monitor 应用程序是事务性数据库，数据库上有大量读写操作。因此，数据库必须针对读写操作优化。而且，数据库的文件系统必须优化以实现高速 I/O。DB2 调优超出了本文的范围，但您可以参考 OLTP 应用程序的 DB2 调优技巧 和 DB2 信息中心 的 Administering 部分了解更多信息。

调优仪表板

仪表板使用 Monitor 数据库生成报告。Monitor 数据库中的仪表板查询的性能是目前为止仪表板性能中最重要的因素。

使用以下指南评估需要做出哪些优化来提高仪表板性能。

• 使用 Dashboard 的 Instances 视图将导致 SQL 查询被直接发送到 Monitor 数据库。这些查询类型的响应时间可以使用标准 SQL 调优操作改进。参考 DB2 信息中心 的 Tuning 部分。
• 使用 Dimensional and Reports 视图将导致多维表达语言（MDX）查询被发送到 IBM DB2 Alphablox。IBM DB2 Alphablox 维护保存最近查询和来自 DB2 的查询响应的缓存。这些类型的查询可以通过调优 DB2 Alphablox 多维数据集改进。参考 DB2 Alphablox 信息中心 中的 Administrator's Guide。
• 关键性能指标（KPI）视图有一个附加的 KPI 缓存，该缓存直接内置于 Dashboard 应用服务器。默认情况下，该缓存是禁用的。为减少 KPI 计算成本并改善系统性能，您可以启用该缓存。按照以下操作设置缓存的刷新间隔：
  1. 选择 Monitor Models。
  2. 选择要编辑的监视器模型的版本。
  3. 更改 KPI Cache Refresh Interval 字段的值。
  4. 单击 OK，然后单击 Save。
  为了优化性能，将刷新间隔值设置得尽可能高。但是，注意这影响仪表板上的数据流动。
• 使用 Monitor 的 Data Movement Service (DMS) 来启用从事件处理表到仪表板表的定期信息复制。将信息复制到单独的仪表板表的好处是，仪表板可以拥有一组自己的表，这些表可以针对仪表板 SQL 读命令进行优化。
• 如果 DB2 Alphablox 已安装，针对每个已安装监视器模型定义的多维数据集在默认情况下将被启用，刷新间隔为一分钟。这意味着每个已定义的多维数据集每分钟重新构建其元数据，从而引发处理开销和数据库操作。从性能角度看，您应该将刷新间隔设置得尽可能高。但是，注意这将影响仪表板上的数据流动。

结束语

本文介绍了 WebSphere Business Monitor Version V6.1 的一些基本性能调优技巧和指南，引导您检查了 Monitor 环境的所有部分，重点讨论了对您的应用程序的吞吐量和响应时间影响很大的参数和设置。

参考资料

• WebSphere Business Integration V6 性能调优：这个 IBM Redpaper 提供关于调优 WebSphere Business Monitor 的更多信息。
  
  
• OLTP 应用程序的 DB2 调优技巧（developerWorks，2002 年）：这篇论文集中介绍几个 DB2 调优技巧，这些技巧基于运行 Online Transaction Processing (OLTP) 类型的性能基准测试（TPC-C、TPC-W、Trade2 等）获得的经验。数据库应用程序的性能受到诸多因素影响。这篇论文只关注 DB2 的配置问题，没有考虑容量计划、数据库设计或应用程序设计方面的细节，但简单提到了几个需要提醒的问题。
  
  
• DB2 信息中心：获取关于 DB2 调优的更多信息。
  
  
• DB2 Alphablox 信息中心：获取关于 DB2 Alphablox 调优的更多信息。
  
  
• WebSphere 业务流程管理专区：获取 WebSphere BPM 解决方案的最新技术资源，包括文章、教程、活动、下载等。
  
  
• WebSphere Business Monitor 培训：WebSphere Business Monitor 的一个课程列表。
  
  
• WebSphere Business Monitor V6.1 信息中心：获取完整的产品文档。
  
  
• developerWorks 网站上关于 WebSphere Business Monitor 的技术文章。
  
  
• 随时关注 developerWorks 的技术活动 和 网络广播。
  
  

• 下载 IBM 产品评估版 ，并开始使用来自 DB2、Lotus、Rational、Tivoli 和 WebSphere® 的应用程序开发工具和中间件产品。

关于作者

		Torsten Wilms 是位于德国 Boeblingen 的 WebSphere Worldwide Technology Practice Team 的 Software Services IT 咨询专家。Torsten 帮助 IBM 客户基于 WebSphere 平台开发和部署业务集成解决方案。他还参与撰写 IBM 的各种技术出版物，并经常在世界各地的技术会议上演讲。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首