这个由两部分组成的系列介绍如何使用 IBM® WebSphere® Process Server
V6.1 中的应用程序响应度量(Application Response Measurement,ARM)标准来监视服务组件体系结构(Service
Component Architecture,SCA)调用。您可以使用诸如 IBM Tivoli® Composite
Application Manager for Response Time Tracking 等 ARM 实现来生成 SCA 调用的图形视图。本文是该系列的第一部分,将首先描述
ARM 并介绍如何使用 Tivoli Composite Application Manager for Response Time
Tracking 来调试同步场景。在第 2 部分中,您将获得关于 SCA 调用模式的介绍,并了解如何调试异步场景。
WebSphere Process Server 引入了 SCA,将其作为构建面向服务的体系结构(Service-Oriented
Architecture,SOA)系统的编程模型。作为企业解决方案,SCA 支持现有的技术,例如 Java™ 和 Web
服务,并创建统一的视图来组装各种实现 Java 或 Web 服务描述语言(Web Services Description Language,WSDL)接口的组件。通常,在设计改进、性能优化或故障排除过程中的运行时期间,您需要监视
SCA 组件。您可以通过分析性能指标来解决诸如故障条件或不可接受的延迟等问题。
WebSphere Process Server V6.1 提供了用于 SCA 调用的观察功能,并支持各种统计信息输出标准,包括公共事件基础设施(Common
Event Infrastructure,CEI)、性能监视基础设施(Performance Monitoring Infrastructure,PMI)和
ARM。通过选择相应的监视点以向 CEI 发出事件,您可以监视某些服务组件,或者可以通过 PMI 或 ARM 获取性能统计信息。
WebSphere Process Server V6.1 中的 ARM 是 SCA 级别的性能度量,与其他格式相比,ARM
可产生有关性能的某些方面的更详细信息。ARM 主要集中于 SCA 中每个流程的完成状态、间隔时间和事务沿袭 (lineage)。由于
ARM 的性质,性能统计信息逻辑地相互联系在一起,从而可以更好地检测 SCA 调用中的瓶颈。
ARM 是一个 Open Group 标准,用于测量应用程序或业务服务的性能和可用性。应用程序在开发阶段中对其进行检测,并在运行时使用它来分析所涉及到的事务。
ARM 的基本功能是记录每个事务的启动和停止时间戳(附带执行结果)。事务通过 ARM 生成的令牌互连在一起,并由应用程序进行传递。在所有事务都完成以后,可以在相关事务的基础上提取出拓扑,并且系统管理员可以分析统计信息以确定代价昂贵和有问题的执行路径在何处。
在某种程度上,ARM 的工作类似于一个功能强大的秒表,并提供了一个包含 start() 和 stop()
条目的接口,就像教练使用的秒表一样。不同的运动员就像各个事务,并且调用链就像接力赛跑,接力棒从一个运动员传递到下一个运动员,非常类似于将事务联系起来的相关令牌。
WebSphere Process Server V6.1 通过一个 ARM 4.0 标准 Java 绑定接受检测,并支持监视
SCA 调用的事务统计信息。注意:WebSphere Process Server 没有附带 ARM 代理;它支持
ARM 标准,这意味着用户将选择自己的实现提供者。(请参阅参考资料,以获取指向
Open Group 网站上的 ARM 标准官方文档的链接。)
在本文中,Tivoli Composite Application Manager for Response Time Tracking
是收集和分析 WebSphere Process Server V6.1 中的 SCA 调用数据的 ARM 实现提供者。这里,您将使用一个单模块、多组件的
SCA 调用场景,作为了解如何提供 ARM 数据的示例(请参见图 1)。在此场景中,所有调用都是通过同步实现来进行的同步调用(请求-响应操作)。(本系列的第
2 部分将对相关模式进行描述)。对于组件 1、2、3、4 和 6,预设的本地处理时间为 0.5 秒;对于组件 5,该时间为 3
秒,是瓶颈之所在。
图 1. 单模块中的 SCA 调用示例
安装和检测
Tivoli Composite Application Manager for Response Time Tracking
引入了客户机/服务器体系结构,其中管理代理收集数据,管理服务器则监视、维护和分析代理所收集到的数据。
在此场景中,您将设置一个带有 WebSphere Process Server V6.1 的客户机和一个管理代理,其中管理代理是一个带有管理服务器的服务器。作为管理服务器设置先决条件的
WebSphere Application Server and IBM DB2® 也安装在服务器端(请参见表 1)。
表 1. 该场景中的设置环境
客户端 |
服务器端 |
WebSphere Process Server V6.1 |
Tivoli Composite Application Manager for Response Time Tracking
V6.1 管理服务器 |
Tivoli Composite Application Manager
V6.1 管理代理 |
WebSphere Application Server V6.0.2 |
|
IBM DB2 Enterprise Server V9.1 |
注意:有关安装和配置的更多信息,请访问
IBM Tivoli 信息中心以获取 IBM Tivoli Composite Application Manager
for Response Time Tracking Installation and Configuration Guide(在左侧窗格中单击
Composite Application Manager for Response Time Tracking >
Installation and Configuration Guide)。
完成安装以后,服务器将识别代理(请参见图 2),因此用户应该能够为代理创建侦听监视器,本文稍后将对此进行介绍。
图 2. 识别出的代理
下一步是客户端上的 ARM 检测:
- 将 armjni4.jar 从 <ITCAM4RTT_INSTALL_DIR>\lib\ 复制到其类文件可由
WebSphere Process Server V6.1 加载的位置。
- 在客户端启动服务器。
- 在管理控制台中,选择 Application servers > ${SERVER_NAME} > Process
Definition > Java Virtual Machine > Custom Properties,并向
Java 虚拟机添加如表 2 所示的条目。
表 2. 要添加的 Java 虚拟机属性
名称 |
值 |
Arm40.ArmMetricFactory |
com.ibm.tivoli.transperf.arm4.metric.Arm40MetricFactory |
Arm40.ArmTranReportFactory |
com.ibm.tivoli.transperf.arm4.tranreport.Arm40TranReportFactory |
Arm40.ArmTransactionFactory |
com.ibm.tivoli.transperf.arm4.transaction.Arm40TransactionFactory |
- 重新启动 WebSphere Process Server V6.1 并运行该应用程序。管理代理缓存 ARM 数据,并将其发送到管理服务器。
- 打开管理服务器管理控制台,您应该在其中看到该事务已被发现(请参见图 3)。
图 3. 已发现的事务
侦听监视器应该根据所发现的事务来进行配置。(请参见图 4)。
图 4. 侦听监视器
- 再次运行该应用程序。该监视器稍后捕获来自代理的性能数据,然后可以生成报告。
分析数据
Tivoli Composite Application Manager for Response Time Tracking
提供了统计或基于实例的视图来分析结果。
- 选择 Dashboard 以查看当前监视器状态,如图 5 所示。
图 5. 监视器状态
- 要在此同步场景中调试单个实例,请单击 Reports > General Reports > Topology,并选择感兴趣的实例。拓扑如图
6 所示。
图 6. 拓扑报告
在此拓扑视图中,ARM 调用链以图形形式重现,这与通过 IBM WebSphere Integration Developer
开发的场景一致(请参见图 1)。
在图 1 所示的级别中,详细的事务按事务名称或 SCA 事件源名称进行分组,其中事务名称由组件的唯一名称、接口名称和操作名称组成:Transaction
Name = SCA.<COMPONENT_NAME>.MethodInvocation._<INTERFACE_NAME>_<OPERATION_NAME>
您可以看到 Component5 在该调用中的本地时间是 3.008 秒。黄色的感叹号表示该组件是整个链的瓶颈(请参见图 7)。
图 7. 调用中的瓶颈
注意:在此视图级别中,事务进行了分组,此级别在大多数情况下已经足够了。如果您想调试组件之间的内部事务,可以单击感兴趣的事务组的标记。与模式相当(本系列的第
2 部分将对此进行描述)的内部事务将显示出来。图 8 显示了展开名为 SCA.com.ibm.xmlns.prod.websphere.scdl._6_0_0.Component5.MethodInvocation_FooInterface_fooOperation
的事务组的示例,该事务组包括 Component4 与 Component5 之间的调用中的两个事务。从图 8 中可以看到,在这个同步调用中,参考端事务仅花了
0.004 秒 (3.006 – 3.002),而目标端事务花了 3.002 秒 (3.002 – 0)。
图 8. 事务的展开视图
实际上,您可以在事务细分报告(请参见图 9)中可视化并容易地识别事务时间长度,该报告包括一个表和一个细分视图。如果细分视图中的某栏太短而无法看到完整的名称,只需选择该栏并在提示消息框中或左侧高亮显示的表中查阅该名称。
图 9. 事务细分报告
在对某个组件执行时间分析时,您将挑选联系在一起并具有共同名称的事务。这是因为,对于某个调用中的两个组件之间的事务,当针对同一个组件时,事务名称是相同的(请参见图
10)。
图 10. 具有相同名称的事务
在细分视图中,事务栏的长度表示每个事务的响应时间。在这个同步请求-响应调用中,本地时间等于响应时间减去下游时间,因此您可以绘制出本地时间的图形(请参见图
11)。显然,Component5 所花的本地时间最长。
图 11. 对事务细分的本地时间分析
如果 Component5 引发 ServiceBusinessException ,则拓扑报告将其标记为红色,因此您可以容易地识别故障点,如图
12 所示。
图 12. 拓扑报告中的故障点
上面的调用是典型的同步调用场景。对于诸如异步调用等场景,事务细分视图稍微有所不同。(本系列的第 2 部分将对此进行描述。)
现在您应该能够使用 Tivoli Composite Application Manager for Response Time
Tracking 作为查看 ARM 数据的实用工具,从而容易地调试并发现 WebSphere Process Server V6.1
中的典型 SCA 同步调用中的瓶颈或故障点。
同步调用类型只是可能的调用类型之一;SCA 编程模型还支持另外三种异步调用:
若要更深入地了解这些调用中的 ARM 事务和使用 Tivoli Composite Application Manager for
Response Time Tracking 的调试技术,请继续关注本系列的第 2 部分。
学习
获得产品和技术
讨论
|