内容


使用 IBM Rational Performance Tester

监控应用程序,第 2 部分

进行实时监控

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 使用 IBM Rational Performance Tester

敬请期待该系列的后续内容。

此内容是该系列的一部分:使用 IBM Rational Performance Tester

敬请期待该系列的后续内容。

实时应用程序监控能够通过 IBM® Rational® Performance Tester 在开发和测试期间预先发现应用程序的瓶颈。这种方法是有用处的,由于它可以在应用程序部署到产品环境前发现问题,这样可以降低应用程序发布后出现的严重的问题。另外,您还可以使用实时应用程序监控来验证开发组修改过的应用程序的性能。

数据收集架构

Rational Performance Tester 中的实时应用程序监控是使用数据收集底层架构(data collection infrastructure,DCI)来进行的。DCI 的任务是把 Application Response Measurement (ARM) 标准事件传送给用户,这个事件是由 ARM-instrumented 的应用程序报告给 IBM® Tivoli® ARM 引擎的(参见图1)。

图1:使用 DCI 的系统架构
系统架构
系统架构

事务流

为了理解整个架构,考虑一下贯穿整个环境的业务事务的流程是有帮助的:

  1. 在监控时,在根事务要执行的机器上的 DCI 必须启动。例如,执行一个对 http://ibm.com/PlantsByWebSphere 的 HTTP 请求就表示应用 PlantsByWebSphere 必须被启动,而且 DCI 要安装在 ibm.com 所在的机器上。
  2. 客户端调用应用程序的 HTTP 事务,这个应用程序是已经 ARM-instrumented 的。您可以使用下面的客户端:
    • Rational Performance Tester: 在测试执行每个页面的 HTTP 请求时,它的行为与浏览器类似。在响应时间分解(response time breakdown (RTB))激活时,Rational Performance Tester 给请求加上 ARM_CORRELATOR 头属性,这就可以激活 DCI 以监控事务。这个客户端可以在根事务将要运行的机器上自动地建立与 DCI 的连接。
    • 网络浏览器:运行给定 URL 的 HTTP 请求。您必须手动地建立到根事务将要运行的机器上的 DCI 连接。
  3. 由于事务调用的应用程序工作在运行环境下,工具代码(或者探针)将会执行(阅读第一部分可以得到有关探针的更多信息)。这些探针将会初始化由 Tivoli ARM 引擎监控的 ARM 事务。
  4. IBM® Performance Optimization Toolkit 代理(下面简称为 Toolkit 代理)是一个基于 Java™ 技术的应用程序,它实现了 Tivoli 提供的 ARM plug-in 接口,目的是用 Tivoli ARM 引擎注册第三方应用程序。当 ARM 事件生成并报告给引擎时,它们同时报告给 Toolkit 代理。事件按照从根事务到所有子事务的层次进行收集和整理。然后转换为按照 Eclipse Test and Performance Tools Platform (TPTP) 跟踪模型格式的事件集合。然后事件集合被传送到展示系统。
  5. 目标系统和展示系统之间利用 IBM® Rational® Agent Controller 互相通讯。这个部件与 Eclipse TPTP 集成,作为 Rational Performance Tester 的基础。这个部件也管理 toolkit 代理(启动和停止监控)。

每个报告给 DCI 的事件都包含 ARM 事务启动和完成时间的信息,这些信息添加到元数据中。这些时间信息有助于进行度量,然后可以对此进行分析以确定是否存在性能问题。元数据能够帮助表示事务在整个事务层次中的上下文和被调用事务的类型。

执行环境

在执行环境中,有两个代理用来实现 Java 性能分析接口:

  • 适时编译(JITI),IBM® Tivoli® Java™ 2 Platform, Enterprise Edition (J2EE™) 监控组件
  • Java™ Virtual Machine (JVM™)。 API 称为 JVM Profiling Interface,有时简称为 JVMPI。

本系列文章的第 1 部分讨论了 JITI。在 Eclipse TPTP 中使用的 JVMPI 代理在 Rational Performance Tester 中已经得到加强,增加了如安全特性、支持与 Citrix 和 SAP 的集成等。

在您设置监控应用程序的性能分析配置时,您需要选择分析类型,以便确定您想要收集的数据类型。根据您选择的分析类型,DCI可以用一个代理进行数据收集,也可能两个代理都使用。代理是按照您的性能分析设置自动选择的。两个代理的区别如下:

  • ARM 代理在以下情景中最有用:
    • 在分析 J2EE应 用程序性能和程序失败时,特别是在事件高度相关的分布式应用程序中。
    • 在分析 ARM-instrumented 应用程序时。例如,如果您ARM了一个数据库,您可以从您的应用程序中观察事件直到进入数据库中,可以看到在数据库中的全部处理过程,然后看到响应的返回,所有这一些都显示在一个序列图表中。
  • JVMPI 代理在以下情况下最有用:
    • 进行内存性能分析时(例如内存泄漏分析)。
    • 在检查对象的相互作用时(例如 UML2 对象关系视图)。在很多情况下,类的相互作用分析足以帮助发现问题,但是您偶尔可能需要进行更深入的对象级别的分析。
    • 在对非 J2EE 的应用程序进行分析时,例如 Java™ 2 Platform, Standard Edition (J2SE™) 或者 Java™ 2 Platform, Micro Edition (J2ME™) 应用程序。

每个代理都具有自己的数据收集特性,如表1所示:

表1:ARM 和 JVMPI 代理之间的数据收集特性的对比

表 1. 表标题
特性ARM 代理JVMPI 代理
提供关联进程和主机远程调用的能力提供不提供
当在性能分析模式中运行代理时回影响应用性能影响小影响大
提供过滤机制根据 J2EE 组件类型(例如, servlet 或者 JDBC), 主机 URL根据包、类和方法
收集内存信息和对象交互(对于 UML 2 对象交互图)没有

两个代理有可能并行地使用,这时执行环境的负载会显著地增加。因此,增加了 profiling interface (PI) virtualizer (Windows 系统下是 virt.dll 文件)。这个部件仅仅对 JVM 识别的内容进行代理。当 PI virtualizer 从 JVM 接收到事件后,它把这些事件广播到它检测到的每个基于 JVMPI 的代理。在这种情况下,那些代理是 JITI 和 Java 性能分析代理。

为了使用Java性能分析代理,您需要增加以下虚拟机参数:

  -XrunpiAgent:server=enabled

当 PI virtualizer 存在时,使用这个 VM 参数:

-Xrunvirt:agent=jvmpi:C:\PROGRA~1\IBM\DCI\rpa_prod\TIVOLI~1\
app\instrument\61\appServers\server1_100\config\jiti.properties,agent=
piAgent:server=enabled

注意参数指定了接收广播事件的所有两个代理。在前面讨论过的工具的配置文件中可以找到同样的配置。

数据收集底层架构(Data collection infrastructure)

为了收集端对端的事务信息,DCI 必须安装在事务通过路径上的所有系统上,如图2所示(更多的端对端事务的信息可参见第一部分)。之所以有这个要求是因为 ARM correlator 跨越了物理机器的边界。因此,当 ARM correlator 从一台机器传递到另一台机器时,在机器上接受 ARM correlator 的 DCI 必须执行一个特殊的过程,称为动态发现

图2:分布式环境下的 DCI
分布式环境下的 DCI
分布式环境下的 DCI

动态发现过程的目的是自动化地添加客户平台和开始对远程方法调用的机器上的 DCI 的监控。这样做的原因是,当一个事务第一次执行时,只有事务路径上的第一台机器的客户端会被添加进来。因此,与其期望您知道任意一个给定事务调用的所有的物理机器并手工添加它们,不如进行自动化的操作。

这个过程设计得可以在 ARM correlator 中传递有关调用机器上的代理控制器(Agent Controller )的信息。因此,在调用 RMI-IIOP 事务时,ARM事件被传递到新发现的机器上的 DCI(RMI-IIOP 代表 Remote Method Invocation [RMI] Internet Inter-ORB Protocol [IIOP])。 这个 RMI-IIOP 事务是由 toolkit 代理进行检测的。这时,toolkit 代理在被调用的机器上使用代理控制器向调用机器上的代理控制器调用一个同样的请求。这个请求再调用机器上已知的客户端,并给新发现的机器建立连接(参见图3)。这样,事务信息依次地从被调用的机器上流动到要分析的客户机。

说明:
在动态发现工作时,代理控制器的安全特性必须关闭。在本文2007年5月初次发布时,安全特性仍然不能全部支持分布式环境。为了关闭安全特性或者检查是否关闭,执行位于代理控制器安装目录下的 bin 目录的 SetConfig 脚本。

图3:动态发现过程
动态发现过程
动态发现过程

在多数情况下,我们的兴趣集中在从应用程序服务中收集事务信息上。因此,有一些数据库系统(如 IBM® DB2®)包括在 ARM 工具产品中。使用这个 ARM 工具可以对端对端事务进行深入的监控。例如,与只能够知道事务从 Java 应用中使用 Java DataBase Connectivity™ (JDBC™) 调用了 SQL 事务相比,分析人员可以从执行特定查询的数据库内部得到事务信息。这些信息可以很大程度上帮助缩小 Java 应用或者软件方案的数据库产生的问题的范围。

  1. 激活端对端事务监控的第一步是简单地按照数据库产品手册的指导激活 ARM 工具
  2. 第二步是在数据库运行的同一台机器上安装 DCI。在监控模式下启动 DCI 将允许数据库事务信息传递给客户机。
  3. 此外,您可以进行配置以便准确地收集数据库上运行的查询。为了激活这个配置,您必须关闭数据库对本地 DCI 的安全性。激活收集 SQL 查询的方法如下(您只能在已经 instrumented 的应用程序服务器上进行以下步骤):
    1. 关闭应用程序服务和 DCI。
    2. 进入以下目录:<DCI_INSTALL_DIRECTORY>/rpa_prod/tivoli_comp/app/instrument/61/appServers/<servername>/config
    3. 打开 monitoringApplication.properties 文件。
    4. 添加以下两行:
      tmtp.isPrivacyEnabled=false
      tmtp.isSecurityEnabled=false
    5. 启动 DCI。
    6. 启动 应用程序服务。
    7. 初始化调用事务的数据收集。

配置 Rational Performance Tester

在您运行性能测试或者性能调度时,可以使用 Rational Performance Tester 中的 Response Time breakdown,响应时间分解特性来查看任何被分析的页面元素的统计。响应时间分解会显示出被测系统的每个部分花费了多少时间。响应时间分解视图与特定的测试或者调度执行的页面单元(URL)关联。这将显示出系统在测试时的内部情况,因为数据收集机制是在系统测试下进行的,而不是负载驱动的。

一般情况下您是在开发期间的测试环境下实时地获取调度,而不是在产品环境下。为了获取调度 ,您必须在测试时激活它,然后指定需要获取的数据的数量。

为了配置性能测试,需要进行以下工作:

  1. Performance Test EditorTest Element Details 中选中检查框(参见图4)。
  2. 如果在 Test Contents 树的最顶层节点被选中,然后在 Test Element Details 中选择 Enable response time breakdown,这样将在性能测试时对每个页面和页面元素进行监控。
  3. 如果仅仅需要监控特定的页面或者页面元素,在 Test Contents 树中进行选择。这将在 Test Element Details中显示选择的项目配置,以便您可以激活响应时间分解。
图4:性能测试中的响应时间分解配置
性能测试编辑器工作区
性能测试编辑器工作区

为了配置性能调度,进行以下步骤:

  1. Schedule Element Details 下,选择 Response Time Breakdown 标签,并选择 Enable collection of response time 数据。这将激活测试列表和 Options
  2. 在激活 response time breakdown data collection 后,设置 logging detail levels(参见图5)。
图5:在性能调度中的响应时间分解配置
工作区
工作区

Response Time Breakdown 页可以让您设置您要在运行时看到的数据类型、这些数据的样本率以及收集所有用户的数据还是特定用户的数据。

  • 激活收集响应事件数据:选择这个选项将激活响应时间分解的收集。这将针对每个页面元素显示响应时间分解。
  • Detail level: 选择 Low 或者 Medium将限制收集的数据数量。这个选择越高,则事务跟踪得越深,收集的数据的数量就越多。例如,当选择 Low 时,只有表层事务被监控。在基于J2EE的应用程序中,就是 Servlet。当增加选择的水平时,就开始收集 J2EE 应用程序的 enterprise JavaBeans™ (EJBs) 和 RMI 的数据。
  • Only sample information from a subset of users: 如果您设置了 detail level 为 High 或者 Medium,则需要设置 sampling rate 以防止日志变得过大。
  • Fixed number of users: 您在每个用户组中选择的作为样本的用户数。除非您有特定的原因收集多个用户的数据,否则您应该选择 Fixed number of users 并为每个用户组指定一个用户
  • Percentage of users: 您从每个用户组中选择的作为样本的用户占的百分比,但每个用户组中至少会有一个用户。

在性能测试中激活响应时间分解不会影响任何性能调度中的响应时间分解。反之依然,在性能调度中激活响应时间分解也不会影响性能测试中的响应时间分解配置。测试和调度是互相隔离的实体。

在进行了合适的响应时间分解配置之后,您必须执行测试或者调度以在负载测试期间初始化应用程序监控。这可以通过使用 Run 菜单来启动测试或者 调度。只有在通过 GUI 运行测试或者 调度时,响应时间分解才能够启动。如果测试或者 调度配置了响应时间分解,使用命令行执行,则响应时间分解的数据不会被收集。

实时观察性能分析

在开发环境中,您可以用以下分析方法收集响应时间分解的数据:

  • 您可以在开发环境中对运行的分布式J2EE应用程序进行性能分析(通过收集 响应时间分解数据)。
  • 您也可以在使用自动化测试工具运行应用程序时进行分析,这样可以让您很容易地重复运行有问题的场景并模拟应用程序的实际负荷。
  • 您可以使用 IBM® WebSphere® Application Server 分析应用程序的 Web 服务组件。
  • 您可以分析非J2EE应用程序或者任何由 ARM 标准支持的其它语言开发的应用程序。

为了收集实时的响应时间分解数据,必须确保您完成了以下几点:

  • DCI必须在所有要收集数据的机器上安装、配置和运行。更多的信息可以查看安装指南。
  • 所有相关机器上的代理控制器(DCI 的一部分)端口必须设置为缺省值 (10002)。
  • 应用程序系统不能包含内部 IP 地址和网络地址转换(NAT)的网络通信。

在从应用程序系统中收集和分析实时的响应时间分解数据之前,您必须建立到 DCI 的连接。首先,要识别将要处理初始事务请求的服务。更明确地说,识别事务请求到达的第一个应用程序服务。

说明:
在您要监控的分布式应用程序中,您不必明确的创建到每个相关机器的连接。通过动态发现过程,在事务流到达相应的机器时,连接会自动建立。

要初始化实时数据收集,执行以下步骤:

  1. 选择 Run > Profile,或者使用工具栏按钮打开 Launch Configuration 对话框(见图6)。
  2. 这个动作让您切换 Rational Performance Tester 的 Profile and Logging 的视图。这个视图激活性能分析工具并在工作台上用不同的视图布局。
图6:Profile 启动配置动作
Profile 启动配置动作
Profile 启动配置动作

Profile Configuration 对话框可以让您创建、管理和运行实时应用程序监控的配置。使用这个方法可以监控那些没有进行自动化监控的J2EE、非J2EE和Web service应用程序,这可以适用于性能测试或者调度的情况。

  1. Launch Configuration 对话框中,选择 J2EE Application,然后单击New (参见图7)。如果您的应用程序不是运行 J2EE 应用服务,而是根据 ARM 标准进行了手工操作,选择 ARM Instrumented Application
  2. Host 页面,选择代理控制器的主机。如果您需要的主机不在列表里,单击 Add,然后提供 host name port number
  3. 在开始运行前测试连接。
图7:Profile 针对 J2EE 应用程序的启动配置:Host 页面
工作区 host 标签页
工作区 host 标签页
  1. Monitor 页面的 Analysis type 中,选择 J2EE Performance Analysis,或者如果您对使用 ARM-instrumented 的应用程序进行分析,选择 ARM Performance Analysis (见图8)。
  2. 如果您想要自定义性能分析设置和过滤器,点击 Edit Options
图8:Profile 针对 J2EE 应用程序的启动配置:Monitor 页面
工作区 monitor 标签页
工作区 monitor 标签页
  1. Components页面,选择您要收集数据的 J2EE components 的类型(见图9)。
图9:用于监控的 J2EE 性能分析组件
编辑 profiling 选项对话框,components 标签
编辑 profiling 选项对话框,components 标签
  1. Filters 页面,指定您要监控的主机和事务。 filters 指示您想要收集的数据类型。它们包括,而不是排除数据(见图10)。
图10:应用 J2EE 性能分析过滤器
编辑 profiling 选项对话框,filters 标签
编辑 profiling 选项对话框,filters 标签
  1. Sampling 页面,您可以限制收集数据的数量。这可以通过选择所有数据收集的 fixed percentage 或者 fixed rate 来实现(见图11)。
    • Sample a percentage of all transactions: 性能分析有选择性地收集和放弃事务。例如,如果设置为25%,则第一个事务调用收集,后面三个不收集。
    • Sample a specific number of transactions each minute: 收集每分钟的前 n次调用(这里 n是指定的值),其余的不收集。因此,您在一分钟之内将从来不会接受到超过 n次的调用。
图11:J2EE 性能分析采样选项
编辑 profiling 选项对话框,sampling 标签
编辑 profiling 选项对话框,sampling 标签

您可以设置 filter 和 sampling 来指定收集多少数据。filter 指定您想要收集哪些事务,而 Sampling指定您想要收集的事务数据的数量或者百分比。Filters 和 sampling 在根事务层次工作。根事务就是不属于其它事务(至少是数据收集有关的事务)的子事务的事务。

因此,在使用浏览器访问一个Web应用时,根事务就是第一次点击到服务的URL请求。 filtering 和 sampling 应用在这个级别。也就是说,如果您设置了事务的 filter,它在 URL 级别工作。如果您设置了 sample,它只收集一些 URL,而放弃另一些。要么是整个 URL,要么都不是,它不会收集 URL 事务的一部分。

如果 Web 应用驻留在多个服务器上,有些 ARM-instrumented,有些没有,只有 instrumented 的服务器被包括进来。例如,如果用户访问了服务器 A,它没有ARM-instrumented,而服务A使用了一个方法调用访问了服务 B,B 是 ARM-instrumented,这样这个方法就是根事务。这时 Filtering 将不会工作,因为它是使用URL而不是方法名字来进行过滤。

同样,如果您正在使用性能测试或者调度产生性能分析数据,根事务将发生在第一个 ARM-instrumented 的测试单元运行时。如果整个测试或者调度都是 ARM-instrumented(也就是说,在顶层测试或者调度单元选择了Enable response time breakdown),这就将仅仅只有一个根事务。这时 filtering 和 sampling 都将是无效的。

  1. 在您开始监控之前,把应用程序设置为在就要出现性能问题的状态。例如,如果一个特定的 Web 页面的动作导致变慢,那就打开这个网页。
  2. 单击 Profile。已经连接的代理和它的主机和过程都将显示在 Profiling Monitor 视图(见图9)。根据您的性能分析配置,如果在分布式环境下工作的话,可能会显示出超过一个的代理。
  3. 通过选择代理并 Start Monitoring 来启动监控。如果性能分析配置中有超过一个代理,启动每个代理。符合您前面设置的应用程序的任何活动都将会记录下来。代理的状态由 <attached> 转换为 <monitoring>,在从代理接收到数据时,状态转换为 <monitoring...collecting>。
图12:J2EE 性能分析的监控
菜单命令
  1. 在应用程序中,执行可以触发性能问题的操作。
  2. 在弹出菜单中选择 Stop Monitoring来停止监控代理。在最好的情况下,断开同代理的连接,以便其它用户可以监控系统。在弹出菜单中选择 agentDetach。对收集数据涉及的每个代理重复这个步骤。

寻找性能问题的原因

很多代码问题都会导致应用程序失败,对每个问题您都必须使用数据收集和分析技术以及合适的工具来研究。典型的应用程序失败包括 stoppages,这时应用程序不期望地中止,以及 lockups,这时应用程序停止响应,例如进入和死循环或者等待永远也不会发生的事件。

在 lockup 的情况下,您可能不会看到任何实际的错误日志。这时可以使用相互作用图,统计图和线程分析工具来发现问题所在。例如,如果问题是死循环,UML 序列图将会显示您在重复调用序列,统计表也会显示方法花费了很长的时间。如果问题是 deadlock,线程分析工具将会显示哪个线程是您期望它工作,但是实际上在等待永远也不会发生的东西。

在您收集了响应时间分解数据后,就可以使用性能分析工具对数据进行分析,以便确定哪部分代码导致了问题。一般来说,您需要首先把问题范围缩减到导致出现问题的部件。然后您可以继续进行分析,把范围缩减到哪个包、类,直到找到导致问题的方法。当您找到出现问题的方法后,就可以直接到源代码中修复了。

您可以在 Test 视图中查看响应时间分解数据,或者如果执行了性能测试或性能调度的话,您可以在 Profiling and Logging 视图中查看。另外,如果您手工运行 J2EE 应用程序或者进行了 ARM-instrumented 配置,收集的数据只能在 Profile and Logging 视图中查看。

跟踪这样的问题可能包括尝试-出错-再尝试的过程,您可以用不同的方式进行收集和分析数据。您可能会找到您自己的最好的工作方式。

Rational Performance Tester 报告分析

在性能测试或者性能调度执行完毕后,Rational Performance Tester 会给用户生成一个缺省的报告。有两种机制用来分析响应时间分解数据(参见图13)。

  • Response time breakdown 统计:给出事务或者子事务对特定页面或页面元素响应事件的表格。
  • Interactive reports: 用图形来表述事务的分解
图13:页面性能报告的样例
页面性能报告
页面性能报告

在这两个报告中,下面的层级提供了对事务和子事务进行组织和分类的结构:

  1. 主机:应用程序执行方法上下文所在的物理主机。
  2. 应用程序:观察到的方法执行的应用程序。典型地,对于J2EE应用来说,就是应用服务。
  3. 应用程序部件 一个组织好的标签或者元数据,给出方法调用的上下文。对于 J2EE 应用程序来说,方法调用可以标记为 Session EJB,也就是应用程序部件。
  4. 包: 类和方法调用上下文属于的包。
  5. 类:方法调用上下文所属的类。
  6. 方法:特定方法的调用。

使用统计视图进行分析

Page Performance 报告中选择 Display Response Time Breakdown Statistics 选项将显示出事务或者子事务对特定页面或页面元素响应事件的表格。首先,有一个 Page Element Selection Wizard (见图14),以便您可以选取特定的页面单元以查看它的事务分解。所有的页面单元都按照各自响应时间的大小降序排列。

图14:Page Element Selection 向导
Page Element Selection 向导
Page Element Selection 向导

Response Time Breakdown Statistics 的顶层视图显示出选择的页面元素的所有的子事务的集合(见图15)。这个视图中有不同的工具用来帮助分析性能问题。

  • 使用左上角的导航信息返回前一个视图。
  • 使用右上角的工具栏,主要功能有:树型界面和简单界面之间切换、增加过滤器、选择显示哪些栏、调转到源代码、在百分比和数值之间切换、导出到 CSV、HTML 和 XML 格式。
图15:Response Time Breakdown Statistics 视图
工作区
工作区

目录(树)的布局也显示出以下层次(图16):

  1. 主机
  2. 应用程序
  3. 部件
  4. 方法

在您的企业环境下的每个主机排成一列。在每个主机下,排列着应用程序。每个应用程序下,排列着部件,等等

树型布局(见图16)有助于您识别响应事件最慢的排列。

图16:响应时间分解统计:树型布局
工作区
工作区

使用右上角的工具栏的第一个按钮可以在树型布局和简单布局之间切换。缺省的布局是简单布局。

简单布局树型布局的平铺版本。如果您想要看到所有的方法而不关心它们之间的关系的话,可以使用这个布局。这样可以快速地看到最慢或者最快的方法。

点击 column heading可以按照该列进行排序。拖动列可以改变它们显示的顺序。除了树型布局的第一列外,其余列都是可以拖动的。选择的页面元素的准确的URL显示在表上方。

每个对象显示四个结果:Base Time、Average Base Time、 Cumulative Time 和 Calls。所有时间单位都是秒。这些时间的定义如下:

  • Base Time 这个对象内部消耗的时间,不包括这个对象调用其他对象的时间消耗。
  • Average Base Time 是这个对象内部消耗的时间,不包括这个对象调用其他对象的时间消耗,除以调用次数
  • Cumulative Time 是这个对象内部消耗的时间,包括它调用其它对象的时间。
  • Calls 是对象被其它对象调用的次数。

动作

图17显示了工具栏按钮(图16中也显示)和它们关联的动作:

图17:工具栏按钮
工具栏按钮
  1. 点击 Filter 按钮(从工具栏左边数第二个)将打开 Filters 窗口。您可以增加、修改和删除用在显示结果上的过滤器。
  2. 点击 Columns 按钮(第三个)将打开 Select Columns页面。这里可以选择表中显示哪些列。在当前工作区中的设置将会应用到工作区中的所有响应时间分解表中。
  3. 点击 Percentage 按钮(第四个)将在显示百分比和绝对数值之间切换。在百分比格式中,表中显示的数据为百分比,而不是实际的数值。百分比表示一个栏目中的值占该栏中所有值之和的百分比。
  4. 点击 Source 按钮(第五个)将调转到源代码(如果可用)。在您点击这个按钮前必须首先选择一个方法。
  5. 点击 Export 按钮(第六个)将打开 New Report 窗口。您可以把 响应时间分解表导出为 CSV、HTML 或者 XML 格式。
  6. 使用左上角的导航信息可以返回前面的视图。

在过去,交付时间和响应时间的计算上有一定的混淆。如果您很熟悉性能测试的话,这里的响应时间并不等于 Rational Performance Tester 定义的术语。要用下面的定义代替:

  • 交付时间: 最后接收到的时间 - 首次接收到的时间
  • 响应时间: 首次接收到的时间 - 首次发送的时间

在查看 GIF 文件的事务分解时,正常情况下您可以看到非常小的交付时间(通常是零)。因为这个文件的数据流是在一个单独的包内到达。然而,如果服务在很长时间后才响应,您一般可以看见服务对文件头的响应比其余部分要快。在这种情况下,响应可以分解到几个包中。

说明:
您总能看到交付时间和响应事件。您也可是看到标记为 DNS Lookup Connect 的事务请求。

交互式图形分析

交互式图形分析主要是使用存在的 Rational Performance Tester 报告对事务分解用图形的方式向下详细(drill-down)的过程。如果您通过选择 Display Page Element Responses 进行响应时间分解的分析(见图13),您可以用柱状图显示出选择的页面的所有页面元素的响应(见图18)。

图18:响应时间分解的图形详细报告
image of workspace
image of workspace

从这个页面元素详细报告中,您可以选择对特定的元素的主机、应用程序和部件、包、类和方法的响应进行更深入的详细活动。柱状图上的鼠标右键上下文菜单可以显示出当前报告中可用的详细动作。例如,如果您正在对特定的事务查看应用程序的响应时间分解,上下文菜单将显示出查看选择的应用程序的应用程序部件的响应时间分解项(见图19)。

在每个详细过程的层次上,导航的路径都会更加详细一些。这种行为提供了一种很容易的方式可以在在分析过程期间跳转到不同报告。您也可以直接在任何详细图上选择直接跳转到Response Time Breakdown Statistics视图中。

图19:组件层详细报告
工作区
工作区

实时观测的性能分析

UML Sequence Diagram 视图中存在一系列的因果依赖事件,这些事件定义为方法实体和出口,也包括外部调用和返回调用(见图20)。特别地,它存在类实例之间的交互作用。这些交互作用的形式是方法调用和调用返回。Trace Interaction 工具的实现扩展了这个定义,推广了进行交互作用的角色,和交互作用的含义。换句话说,工具提供的视图不仅仅可以显示类和类实例的交互作用,而且可以显示线程、进程和主机之间的交互作用。这种扩展的主要原因是在大型分布式应用程序的跟踪时需要提供分层次的数据表示形式。

图 20:UML Sequence Diagram 视图
工作区
工作区

可以用视图连接服务来帮助分析相互关联的应用程序跟踪事件,这个服务在 UML Sequence Diagram 视图和统计和日志视图中都可用(见图21)。关联使用两个事件的发生的时间来计算。如果没有找到精确的时间匹配,则选择可接受范围内的下一个时间最接近的事件作为关联事件。

图21:在 UML Sequence Diagram 和统计/日志视图的视图连接服务
快捷菜单
快捷菜单

Execution Statistics 视图显示应用程序执行时间的统计结果(见图22)。它可以提供诸如方法调用次数和执行每个方法的时间的统计。这个视图在包、类、方法和实例的层次可用:

  • Base Time: 对任何调用,它是执行调用的时间消耗,不包括在调用期间调用其它方法的时间消耗。
  • Average Base Time: Base time 除以调用次数
  • Cumulative Time: 对任何调用,它是从一个调用中执行其它所有方法调用所花费的时间。如果一个调用没有附加的方法调用,Cumulative Time 则等于 Base Time。
  • Calls: 方法调用次数
图22:Execution Statistics 视图
image of workspace
image of workspace

提示:
可以对整个方法列表按照 Base Time 大小排序。这样将把最消耗处理时间的方法排在最上面。为了这样做,可以选择项目,然后用鼠标右键菜单打开 various analysis 选项。从 Execution Statistics 视图中选择项目,然后就可以显示鼠标右键上下文菜单(见图23)。

图23:Execution Statistics 视图的鼠标右键上下文菜单
右键点击上下文菜单
右键点击上下文菜单

在这个菜单中,下面的选项值得您去执行:

  • Open Source: 如果源代码导入了当前的工作区,这个选项可以让您自动地打开与选择的包、类和方法关联的源代码。
  • Method Invocation Details: 提供有关选择的方法的统计数据,包括有关调用的方法和方法被其它方法调用的信息。您可以在任何分析视图中(如 Method InvocationExecution Flow 或者 Execution Statistics)选择一个方法,然后打开这个视图(见图24)。
图24:Method Invocation Details 视图
详细视图
详细视图

Method Invocation Details 视图显示以下内容:

  • Selected method: 显示方法的细节信息,包括选择的方法被调用的时间、类和包的信息、以及时间消耗。
  • Selected method invoked by: 显示调用该方法的每个方法的信息,包括调用该方法的次数、调用该方法的时间。
  • Selected method invokes: 显示该方法调用其它方法的细节信息,包括调用的方法名、调用的方法时间、调用方法的次数、被调用的包和类的信息,被调用方法的时间消耗。

使用 Rational Performance Tester 进行应用程序监控的三部分系列文章的第 2 部分到这里就结束了。查看以下资源可以得到本系列的其它部分和其它有用的信息。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational, WebSphere
ArticleID=266454
ArticleTitle=使用 IBM Rational Performance Tester: 监控应用程序,第 2 部分
publish-date=10122007