使用 WebSphere Business Integration Message Broker for z/OS 进行消息流的性能分析

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

级别： 初级

Emir Garza (emir_garza@uk.ibm.com), IT 咨询专家, IBM Hursley United Kingdom

2004 年 9 月 01 日

本文研究了分析复杂消息流性能的方法。使用两个容易使用的方法来计算 WebSphere® Business Integration Message Broker for z/OS V5 消息流中每条消息的 CPU 成本。本文通过比较在不同数目的线程和执行组下运行该消息流的结果说明了使可伸缩性最大化的方法，并且使用不同的计算和统计收集设置详细说明运行消息流的 CPU 成本。

引言

本文基于对复杂生产消息流的分析，并且将说明以下这些问题：

• 每条消息的 CPU 成本是什么？ 计算 CPU 成本介绍了两个简单的方法来计算消息流中每条消息的 CPU 成本。
• 额外的线程或更多的执行组，对于可伸缩性哪个更适合？参见 线程对执行组来得到在不同数目的线程和执行组下运行该消息流的对比结果。
• 计算和统计的开销是什么？ 计算和统计开销 显示了在不同的计算和统计收集设置下运行消息流的 CPU 成本。

文章首先在下面的 测试环境和方法部分描述了环境、工作量（workload）以及测量方法。

免责声明

按照性能测量的惯例，使用健康警告（health warning）是明智的。这些测量结果来自于对一个消息流的分析。它是从真实的应用程序中获得的一个实例，并且同样地与简单的测试流相比，它是真实工作量的代表。但是，把本文提出的结果一般应用到所有的生产消息流的假设是不切实际的。

结果摘要

对于被测试的工作量，测量显示：

• 执行组比额外线程具有更好的可伸缩性。
• 收集计算和统计的 CPU 开销最多是 3%。

本文档假设您熟悉 WebSphere Business Integration Message Broker 的概念和操作。有关这里讨论话题的详细信息参见 WebSphere Business Integration Message Broker 文档（在 WebSphere Business Integration Message Broker Toolkit 中可用的帮助）或 WebSphere Business Integration Message Broker 指南（可利用的 PDF 格式）。

回页首

测试环境和方法

测试配置概述

本部分是测试安装程序的高级视图，该测试安装程序带有驱动程序和运行在相同的 LPAR 上并且连接在同一队列管理器的消息代理：

消息流

本文的消息流是从真实的应用程序中获得的。该消息流具有如下特征：

• XML 输入消息：630 字节
• 总共 75 个节点：在这些测量中，14 节点处理消息，如下：
1. MQ 输入
2. 检查
3. 计算（非常繁重的 ESQL 处理）
4. MQ 输出（输入消息的拷贝）
5. 检查
6. 计算节点
7. ResetContentDescriptor
8. 计算
9. ResetContentDescriptor
10. 数据库（插入）
11. ResetContentDescriptor
12. 过滤
13. 计算
14. MQ 输入

驱动程序

批处理程序驱动所有的测试。该程序：

• 发出 MQPUT 来在消息流输入队列中放置 630 字节的非持久性消息。
• 发出 MQGET 来同步的等待消息流输出消息到达输出队列。
• 对于特定数量的消息循环返回到 MQPUT。

并行运行的驱动程序任务数量和消息流线程或执行组的数量一样。

批处理程序是 OEMPUTX，可用于 SupportPac IP13、 WebSphere Business Integration Broker - z/OS 上的取样测试和性能。

测量环境的硬件和软件

硬件配置是：

CPU

4 个逻辑区分的 zSeries 900 Model 116 （2064 - 116）。CPU 不是专用的。它的处理能力和 2064-1C4 的相似。

内存

4000 MB 物理内存。 DASD: FICON-connected Enterprise Storage Server (ESS) Model 800.

软件层为：

操作系统

z/OS 1.4.

队列管理器

WebSphere MQ 5.3.1.

消息代理

WebSphere Business Integration Message Broker 5.0.1.

数据库

DB2® UDB 7.1.

回页首

计算 CPU 成本

使用系统显示和搜索工具

测定消息流 CPU 成本的最容易的方法可能是使用系统显示和搜索工具（SDSF），在大多数的 ISPF 主菜单中通常是选项 “S”。该方法与通过它的简单性带来的补偿相比，精度的缺乏显得更突出，但是该方法仍然给出了一个显示 CPU 成本的好方法。

SDSF DA（活动显示）通过地址空间以秒为单位显示花费的 CPU 时间。这允许根据测量前后的时间差异计算消息流的 CPU 成本。

限制：只有当 CPU 时间根据地址空间而不是 WLM enclaves 管理时，该方法才可以工作。该方法在大多数情况下是正确的。例外的是当存在由 WLM 控制的 DB2 存储过程时，该存储过程会引起创建 enclave。

使用 SDSF 计算 CPU 成本：

1. 设置 SDSF 过滤器显示相关的地址空间。通常有代理、队列管理器和 DB2。其它工作量可能包括 CICS 或 IMS。
2. 转到 SDSF.DA。
3. 在命令行，输入 prefix ** 和 owner **。该命令会导致显示所有的地址空间。
4. 从 Action 栏，选择 Filter，并且输入过滤标准。例如，参见下面的图 2：
   
   图 2. 显示任务名称和值
   
   
   结果应该显示 DB2 地址空间（任务名称以“DF25”开始）、队列管理器和代理（任务名称以“VEG3”开始）。
5. 在测量前，拷贝 CPU 时间值并且把它们粘贴到电子表格。
6. 提交与“测试驱动程序”下的描述类似的测量任务。
7. 测量结束后，再次拷贝和粘贴 CPU 时间值，并且计算 CPU 时间差。
   您的电子表格应该看起来如下：
   
   图 3. 电子表格结果
   
   
   
   在实例中，总的 CPU 时间是 52.3 秒。测量任务放置了 1000 条消息，所以每条消息的 CPU 成本是 52.3 微秒。这是捕获的 CPU 时间。
   
   捕获的 CPU 时间是操作系统能可靠地用于一个特定的地址空间的 CPU 被占时间。通常 CPU 使用的一部分不会用于特定的地址空间，这部分时间叫做 未捕获的 CPU 时间。对于大多数工作量，捕获的 CPU 时间通常占总 CPU 时间的 90%（未捕获的时间占剩余的 10%）。
   
   把捕获比考虑进去后，在这种情况下，每条消息的总 CPU 成本是：
   52.30 ms/msg / 0.9 = 58.11 ms/msg.
8. 重复几次所有的测量，确保结果是一致的。

使用 OEMPUTX

使用驱动批处理程序 OEMPUTX 执行了本文提到的所有测量。该程序可用于 SupportPac IP13、WebSphere Business Integration Broker - z/OS 上的取样测试和性能。您可以下载 SupportPac IP13。

OEMPUTX 在循环中放置特定数目的消息，然后使用测量结果写一个报告。下面是上文提到的同一运行的报告：

Message file: DD:MSGIN
 OEMPUTX about to MQCONN to QMgr VEG3.
 OEMPUTX about to MQOPEN request queue: MQSI.IN
 OEMPUTX about to MQOPEN reply queue: MQSI.OUT
 Clearing out reply queue... 0 message(s) deleted
 CPU type 0323EA2064
 Date Time 2004/03/19 12:15:23.
 Entering PUT/GET loops (MQGET_Wait=60 seconds)...
   Message size        : <Determined by Message File data>
   Message persistence : NON-PERSISTENT
   Messages per loop   : 1
   Total messages      : 1000
   Syncpoints          : NO-SYNCPOINT
   MQGET replies by    : Any message
 Starting loop at 2004-03-19 12:15:23.073071
 -------------------------------------------------------
 Total Transactions  : 1000
 Elapsed Time        :   55.483 seconds
 Application CPU Time:    0.176 seconds  (0.3%)
 Transaction Rate    :   18.024 trans/sec
 -------------------------------------------------------
 Round trip per msg  :    55482 microseconds
 Avg App CPU per msg :      176 microseconds
 -------------------------------------------------------
  Jobname.ASID  TCB(uS)  SRB(uS)  Tot(uS) (%)
                /tran    /tran    /tran
 ------------- -------- -------- -------- ----
 VEG3MSTR.008D 00000012 00000021 00000034 0.1
 VEG3CHIN.5004 00000003 00000002 00000006 0.0
 VEG3BRK .0098 00000178 00000012 00000190 0.3
 VEG3BRK .008E 00051675 00000020 00051696 93.2
 VEG3BRK*      00051854 00000033 00051887 93.5
 DF25MSTR.00AE 00000023 00000260 00000284 0.5
 -------------------------------------------------------
 Ending loop at 2004-03-19 12:16:18.557166
 OEMPUTX Normal Exit: End of program
 Exiting at 2004-03-19 12:16:18.566099

参见 SupportPac IP13 获得有关 OEMPUTX 全面的描述。 OEMPUTX 报告的最后部分以微秒每消息为单位显示了每个地址空间的 CPU 成本。

为了计算 CPU 成本，根据该电子表格实例，简单地把值加起来：

观察 OEMPUTX 按照单个代理地址空间报告 CPU 成本。报告也给出了总的代理成本（如“<broker name>*”），为了避免计算两倍的代理成本，该值从总和中删除。

每条消息的往返传递（Round trip per message）时间（由 OEMPUTX 观察到的响应时间）是 55.482 微秒。这非常接近每条消息的 CPU 成本 52.21 微秒。这表明工作量是受 CPU 限制的（对于受 I/O 限制的，消耗时间要比 CPU 时间高，差别是花费在等待完成 I/O 操作的时间）。

回页首

线程对执行组

下面的表格以消息率的升序排列显示了在不同数目的线程和执行组下运行消息流的结果。

下面的图表显示每种情况能达到的消息率：

对于固定的工作量而言，额外的执行组比额外的线程具有更好的可伸缩性。观察得到用 3 个执行组消息流得到的消息率比用 4 个线程时得到的稍微高一点。

没有使用高于 4 个线程或执行组的运行，是因为硬件只有 4 个 CPU。对于像这样的受 CPU 限制的工作量，拥有比 CPU 多的线程（或执行组）将导致收益递减。这主要是由于额外的任务转换。 对于受 I/O 限制的工作量，更多的线程（或工作组）可以导致更高的消息率，因为在其它线程等待完成 I/O 操作时，CPU 可以处理消息（当然，假设消息流使用的 I/O 设备不是饱和的）。

值得重申的是该结果不能应用于所有的情况，并且对于其它工作量而言，额外的线程可能比额外的执行组提供更高的消息率。

回页首

计算和统计开销

WebSphere Business Integration Message Broker（原来的 WebSphere MQ Integration Broker 或 WMQI）Version 5 的一个新功能就是收集计算和统计的功能。

许多喜欢使用该功能收集长期数据的用户询问该功能的开销是什么。该部分尝试为 WebSphere Business Integration Message Broker for z/OS 的用户提供答案。

下表显示了不同的计算和统计收集设置的 CPU 成本（微秒每消息）。

每行显示一个测试运行的结果。第一行是在计算和统计收集关闭条件下最基本的运行。其它所有的运行与该运行做比较。

下面的行是对应不同设置的运行：

• 头两列显示对测量时间的收集（Archive 或 Snapshot）活动的类型。除了最后一个，所有的运行都使用 Archive 收集；这是因为 Archive 是最适合收集长期数据的类型。
• 接下来的两列显示 Thread 和 Node 的设置。用户可以通过线程和/或节点收集统计数据，节点统计有两个详细的级别（basic 或 advanced）可用。 None表示不收集。
• 接下来的一列显示总的 CPU 成本（微秒每消息）。这包括 Message Broker、WebSphere MQ 和 DB2 地址空间。
• Total Overhead 显示了在与最基本的运行比较时在总 CPU 成本中的百分比差别。
• 最后两列显示了 CPU 成本和相应的执行组地址空间的收集开销。

使用最高的可能存在的粒度（thread=basic 和 node=advanced），在 z/OS 下，Message Broker 计算和统计收集的 CPU 开销大约是 3%。这对于大多数的用户来讲是可以接受的。可是需要重申的是其它工作量可能有不同的开销。

回页首

结束语

本文描述了两个容易使用的测量 Message Broker 流中每条消息的 CPU 成本的方法。测量显示，对于测试工作量，额外的执行组比线程提供了更好的可伸缩性。Message Broker Version 5 提供了一个收集计算和统计的新功能。对于测试工作量来讲，使用新功能的开销最多是 3%。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  

关于作者

		Emir 是基于英国 IBM Hursley Laboratories 的 IBM Software Group Services for WebSphere 的一名 IT 咨询专家。Emir 专门研究 Business Integration 软件。他从 1999 年就开始使用 WebSphere MQ 工作并且从 2000 年开始使用 WebSphere Message Broker。

对本文的评价

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

回页首