内容


使用 IBM Rational Performance Tester 对一个模拟在线书店进行压力测试

Comments

本文讲述了 IBM Platform Evaluation Test(PET)团队在模拟的 Web 书店站点上实现 IBM® Rational® Performance Tester 的 Linux® 操作系统版本的过程中的经历。在 Rational Performance Tester 出现之前,我们对用户模拟软件的选择局限于非商业产品,例如 IBM Web Performance Tools 试验项目和 Siege。这两个都执行基本的 Web 会话功能,例如记录和回放,但是缺少许多商业产品,例如,Rational Performance Tester,中的有用特性。本文中我们讨论了首次使用 Rational Performance Tester 的经历,以及与 WPT (作为基本的用户模拟工具) 如何比较。我们还讨论使用数据池和定制代码特性的经历。最后,我们分析对书店站点压力测试环境的额外增强的潜力。

书店站点概况

书店站点是一个 IBM zipSeries® Web 应用程序,只在 IBM 中使用,它模拟大型在线书店,例如 BarnesAndNoble.com。它是一个复杂、多层次、多平台的环境,它被设计用来模仿真实的客户场景。书店可以跨 IBM Systems p®、z®、i®,和 x® 硬件,在这些硬件上要运行 IBM DB2、IBM WebSphere® Application Server 和 IBM WebSphere® MQSeries® 软件。我们已经使用 WPT 来模拟拥有上百万书籍的书店,在真实客户使用之前找到并解决软件、硬件,以及集成问题。

要了解更多关于模拟 Web 书店应用程序的详情,请参见相关的文章和实例。

用户模拟工具的描述

IBM alphaWorks® Web Performance Tools

我们评估了三个站点测试工具:IBM Web Performance Tools、Siege 和 IBM Rational® Performance Tester。

IBM Web Performance Tools 产品(WPT)是由 IBM alphaWorks 开发的一个试验项目,BM alphaWorks 是 IBM 的新兴技术部门。现在不再将 WPT 进行增强了,因为在试验阶段证明了它非常有用,可以将其作为商业产品继续开发。因此,它的功能已经被并入到了 Rational Performance Tester 中。

WPT 最初只运行在 IBM AIX® 平台上,并被称为 AKstress,而它最新的版本使用了 Web Performance Tools 的名称。最新的版本在其他平台上也可以使用,包括 Linux 操作系统。WPT 包括两个主要程序:压力和记录。

  • 压力工具是一个简单的、高性能的、使用线程的 HTTP 引擎,它模拟高强度压力的 HTTP 客户负载。它可以使用脚本并提供有用的统计数据及日志。
  • 记录工具使得为压力测试创建脚本变得容易。

Siege

Siege 是拥有类似于 WPT 特性的 GPL 软件。随着时间的推移,我们注意到,其性能也类似于 WPT。因此,我们感觉将其与 Rational Performance Tester 进行正式地比较是冗余的。

IBM Rational Performance Tester

这是用于生成用户负载的商业化的 IBM 产品。它作为 IBM 软件开发平台(software development platform,SDP)的一个插件,并且目前只支持在 Microsoft® Windows® 操作系统和 Linux 上使用。Rational Performance Tester 包括一个 IBM Rational ClearCase® LT 的完整功能的副本,再加上以下这些关键特性:

  • 用于创建、修改,并执行工作负载的可视化测试编辑器
  • 能够同时运行多个,以及各种各样的用户模拟
  • 跨节点分配测试作业的可部署的执行代理
  • 立即的性能及吞吐量报告
  • 动态服务器响应的自动识别,及对其的支持
  • 使用数据池随机的输入
  • 服务器资源数据的集合及可视化
  • 生成在测试记录过程中被访问的 Web 页面的 HTML 视图
  • 为了灵活定制测试,可以插入 Java™ 代码

成功的书店用户模拟的预测试需求

ZipSeries 软件的一个关键的方面是高要求下的高可用性。过去,我们经历了数周时间不断的寻找,以帮助确定书店的哪些部分易于失败。因此,对于我们测试的最初阶段来说,我们设定了以下对 Rational Performance Tester 的目标和需求:

  • 必须在功能上是可接受的。它必须能够再现所捕获屏幕的确定集,用于基准测试及产品共存。
  • 必须能够可靠地运行很长一段时间。至少,它必须在不需要人工干涉的情况下,运行几周。
  • 必须能够生成充足的压力工作负载。目前由 WPT 生成的事务速率将被用作比较的基准点。因而,Rational Performance Tester 必须能够达到或超过目前速率 15% 以内 。
  • 应该很容易安装、配置及运行。最好是,我们能够使用命令行脚本来开始并停止我们经常运行的测试。

用户的随机输入目前由 zipSeries 软件管理,因为,作为试验项目,WPT 有局限性。因此,为了更准确地对真实世界的使用建模,我们还想要使用只有 Rational Performance Tester 才有的特性,来将随机输入加入测试软件。

测试环境

我们使用 IBM Rational Application Developer Version 6.0.1.1 FixPack 2,Java 1.4.2,在 Red Hat Enterprise Linux WS 3(内核 2.4.21-40.EL)中开发。我们还使用开发环境来进行大多数测试,这就是为什么在本报告的后面我们把它称为“测试机器”的原因。该计算机是 IBM NetVista 8305-R8U,2.4 GHz Pentium 4 处理器,1 GB 内存(RAM)和 2 GB 交换区和 35 GB 硬盘。我们在 IBM X345 机器的 Red Hat Enterprise Linux AS 3(Kernel 2.4.21-20.ELsmp)上运行扩展测试,该机器有两个 3.2 GHz Xeon CPU,3 GB 内存(RAM)及 2GB 交换区(SWAP)和 15 GB 磁盘存储空间。

Web 环境存在于运行有 AIX V 5.5 TL4 ServicePac® 2 的 IBM POWER® 5 ML3 系统上。该环境在 IBM WebSphere Application Server V 6.0.2,FixPack 7 上运行 zipSeries 书店应用程序。两个书店的数据库服务器(浏览及购买)在依据某种规范(等同于 WebSphere Application Server 机器上的规范)的硬件上运行 DB2 UDB V 8.1。另一台 WebSphere Application Server 机器用于运行被测试的 Web 服务,并运行在 Red Hat Enterprise Linux AS 3 (kernel 2.6.9-22.0.2.ELsmp)和 IBM e325® 系统上,该机器有两个 2 GHz Opteron CPU,3 GB 内存和 2 GB 交换区及 15 GB 磁盘空间。

测试机之间的网络连接是通过光维的 Gigabit Ethernet 实现的。对于测试,我们使用 Web Performance Tools V 1.9.4 和 Rational Performance Tester V 6.1.2 FixPack 2 的 Linux 版本。

实现经历

在本部分中,我们将说明我们所遇到的问题。注意,尽管 Rational Performance Tester 支持在 Linux 上运行,但它在 Windows 平台得到过更多测试。因此,我们在此列出的某些问题可能不适用于 Windows 版本。

安装

我们从 IBM 的内部 Web 站点下载 Rational Performance Tester 安装程序。安装是直接的,并且需要很少的交互,但要花费很长时间来完成 —— 在类似的硬件上要四个小时。在安装之后,需要立即更新 Rational Performance Tester 和之前所有其他安装过的 IBM 软件开发平台(software development platform,SDP)的软件。推荐:如果您有很多磁盘空间,那么就保存安装镜像。如果您需要从头开始重新安装 Rational Performance Tester,保存镜像会节省时间。

运行 Rational Performance Tester

通过 SDP 的 Test 视图(透视图)可以访问 Rational Performance Tester。推荐:在 Linux 平台上,除非您设置 MOZILLA_FIVE_HOME 环境变量,否则集成的 Web 浏览器可能会工作不正常。应该指向的是 Mozilla 的安装目录。在我们的开发系统中,是在 /usr/lib/mozilla-1.7.12。

工作区崩溃

有的时候,SDP 可能会崩溃或挂起,或者工作区会工作不正常,拒绝重新打开。推荐:关闭 SDP,将 .metadata 文件夹从工作区目录中删除,重新打开 SDP,从文件系统中导入项目文件夹。

日志位置

错误消息常常在某些日志中,尽管这些日志在哪儿不是很明显。这里是日志的位置:工作区中的 .metadata 文件夹中的 .log 文件包含了发送到屏幕上的所有错误信息。它包含 SDP 返回的部分异常,但不是全部。推荐:

  • 当启动 SDP(通过 rationalsdp.bin)时,将所有输出重定向到一个额外的文件是一个好主意。
  • 工作区的 .metadata 文件夹中也有 CommonBaseEvents 日志。这些大部分包含来自于 SDP 的编译时错误和警告。运行时错误在其他地方,Problem Determination Log 中。在工作区的 deployment_root 文件夹中,打开最近修改的子文件夹,并分析此处的 CommonBaseEvents 日志。以 00 结尾的是最近的。有时候,出自 Problem Determination Log 中的条目在测试/进度执行历史中是可见的,但不总是。
  • 此外,一些错误消息只在执行历史中可见,并且不会写入日志。在进度测试过程中,务必在进度中将 Problem Determination 和 Execution History 记录设置为All

最大化数据池尺寸

Rational Performance Tester 包含一个对表单随机输入数据的特性。您可以创建一个数据池来指定所使用的值。整个数据池在运行时加载入内存。这是确保测试的运行时准确性的特性。然而,这也使得数据池的最大容量依赖于可用的内存总量。可以配置 Rational Performance Tester,通过 Java™ 虚拟机(JVM™)的参数来使用更多系统内存,但这对非常大的数据集(在 3 GB 内存的机器上大约有 10,000 个值)是不够的。

推荐: 我们使用 Rational Performance Tester 的定制代码 特性,为数据池方法创建另一个选择,不强制一次性加载所有数据。(参见下一个部分)。

使用带有定制代码特性的 J2EE

在下面的测试及处理部分中,我们将更详细地讨论为什么我们需要使用 Java™ Platform 2,Enterprise Edition(J2EE™)的功能,特别是 Web 服务。注意该提示的一些部分将应用于引入定制代码中所使用的任何外部库。推荐:

  1. 首先,一个建议:在用为定制代码使用之前,确保该程序在 IBM Rational® Application Developer 中可以作为独立的项目正确的工作。
  2. 请注意有两个 Rational Application Developer 项目的 .classpath 文件中的两个条目,这两个条目需要在稍后保存。切换到Resource 视图,观察 .classpath 文件。第一条是针对 WebSphere Runtime Library 的,第二条是来自于需要显式地被引入的库(如果您计划使用 Web 服务的话)中的 JAR 文件。
  • <classpathentry kind="con" path="com.ibm.wtp.server.java.core.container/
    com.ibm.ws.ast.st.runtime.core.runtimeTarget.v60/was.base.v6"/>
  • <classpathentry kind="lib" path="/opt/IBM/Rational/SDP/6.0/runtimes/
    base_v6/lib/objectpoolimpl.jar"/>
  1. 在创建了定制代码,并在测试项目的 .classpath 文件中引入适当的条目之后,打开 Project Properties 窗口。考虑在测试项目的 build 路径中引入您的独立项目。
  2. 确保在 OrderExport选项卡中选择了 JRE System LibraryWebSphere V 6.0 Runtime
  3. 然后关闭 Rational Performance Tester,停止 IBM Rational® Agent Controller(或 RAServer),重新启动,然后重新启动 Rational Performance Tester。
  4. 在启动测试之前,始终确保在 Order 和 Export 中标记出适当的库。有时候,Rational Performance Tester 不保存 Order 和 Export 设置。如果一个项目被导出,而又被导入到一个新的工作区中的话,这一点就特别值得注意。

如果这仍旧不能满足您,您可以考虑显式地将所有必需的 JAR 文件引入到项目的 build 路径中,而不必在运行时使用 WebSphere V 6.0。如果您正在使用 Web 服务,就可能引入以下 JAR 文件:

  • bootstrap.jar
  • channelfw.jar
  • channel.http.jar
  • channel.tcp.jar
  • commons-discovery.jar
  • ffdc.jar
  • j2ee.jar
  • objectpoolimpl.jar
  • runtimefw.jar
  • webservices.jar
  • wsdl4j.jar

IBM 技术支持建议您在启动 Rational Performance Tester 之前将所有必需的 JAR 文件引入到 class 路径环境变量中。然而,对于我们来说,这没什么区别。在 .classpath 文件中显式地引入这些(JAR)文件对我们也完全没有作用,但这使我们对我们需要做些什么有了更好的了解。

例如,如果在测试运行时 JVM 不能找到定制代码所需的类,那么 IBM Rational Agent Controller 将忽略定制代码并认为它应该返回 null。当定制代码返回 null时,将不做任何操作。当这种情况发生时,您也许会,也许不会在测试/进度执行历史中获得错误信息。通过使用定制代码中的 Class.forName() 方法,当某个必要的类在测试运行时对 Rational Performance Tester 是不可用的时候,我们能够获得异常。

即使所有必要的类在运行时对 Rational Agent Controller 和 Rational Performance Tester 都是可用的,您的依赖于 J2EE 的程序也仍旧可能不工作。在我们的案例中,调用ServiceFactory.newInstance() 直接导致 JVM 错误。推荐:一种解决方案是使用 java.lang.reflect 包并按此方法调用:

  • Class c: Class.forName("javax.xml.rpc.ServiceFactory")
  • Method m: c.getMethod("newInstance", null)
  • Service s: (Service)m.invoke(null, null)

如果您调用带有参数的方法,请参见 Java Reflection 文档。

内存使用

在我们的测试机上,当在测试进度中允许默认的记录时,超过五个用户参与的短期(10 分钟)测试就导致了内存溢出错误。因此,在确保所有内容都能正确工作之后,我们就将所有记录设置为none。如我们在下面的测试及处理部分中所描述的,为了负载分析的目的,我们不需要 Rational Performance Tester 的记录特性。

批处理执行

Rational Performance Tester V6 通过 cmdlineexecute 插件,支持 Windows 上的批处理执行。然而,在 Linux 上这个特性要到 Rational Performance Tester Version 7 才能实现,这要等到 2006 年底或 2007 年初的版本。

只有 root 用户才能进行的操作

如果您以非 root 用户身份运行,那么 Rational Performance Tester 的一部分内容不能正确地工作。我们具有以 root 身份和以非 root 身份混合运行 Rational Performance Tester 的经历。有时候有效,有时候无效。推荐:总以 root 身份运行 Rational Agent Controller。

测试及处理

我们进行四个不同的测试,以确定 Rational Performance Tester 是否满足我们的需求。

性能比较测试

这是我们用来评估 Rational Performance Tester 在我们的环境中替代 WPT 的潜能的主要测试。我们最关心的是,与 WPT 比较,Rational Performance Tester 生成压力负载的能力。我们还关心来自于测试机的被所需资源。

测试。使用 Rational Performance Tester 和 WPT 中的记录工具,我们创建一个访问 zipSeries 书店 Random 页面的测试。该页面调用 SetRandom servlet 随机地从书籍列表中选择书籍名称,然后模拟购买。用户可以在 Random 页面上指定要选择多少书籍,及要买多少。我们让每个工具使用 Random 页面搜索完整的名称列表,然后选择任意一本书。SetRandom 还至少对每次随机搜索(不论是否指定购买)设置一次购买。因此,该测试有效地模拟了一次随机浏览和一次购买,因而,每次有两个事务。

Random 页面终止于自动地注销用户会话,这样可以帮助释放 WebSphere Application Server 的资源。因此,Random 调用的结果从来不实际地显示在 Web 浏览器中,而我们只将 Random 页面用于测试。

记录的测试被修改了,以便在不首先访问默认的 Random 页面的情况下,直接将参数提交给 SetRandom。这减少了不必要的 HTTP 通信。返回给压力程序的唯一数据是注销页面。

WPT 使用客户端(clients)线程(threads)的概念,客户端(Rational Performance Tester 术语中的用户)负责开始所记录的测试,并访问指定的 Web 首页。客户端线程负责完成模拟,这意味着在测试中访问其他需要记录的页面。Rational Performance Tester 也使用线程,但最终用户不能以同样的方式对线程进行控制。这就是为什么我们让测试在模拟过程中只访问一个页面的另一个原因,因为这样更利于比较。在 WPT 记录过程中,我们将每个客户端的线程数设置为 1(一),但由于只需要访问一个页面,所以该数字是不相关的。(参见参考资料中的 Web Performance Tools V 1.9 User's Guide,WPT.pdf。)

注意:
访问是直接到 WebSphere Application Server 端口的,不是通过 IBM HTTP 服务器转发的。

度量:虽然 Rational Performance Tester 和 WPT 都提供了测试运行统计数据,但是我们使用自己的机制来衡量它们的能力。我们通过所进行的数据库事务的数量来衡量负载,不以所访问的 Web 页面来衡量,并且我们通过被记录的 vmstat 日志来衡量本地资源。

我们有一个建立在 WebSphere Application Server 中的程序,可以将 WebSphere Application Server 所进行的所有数据库事务放入一个文件中。随着时间的推移,该文件被解析并提交到我们的 SLA 数据库中。我们称其为scraper方法。最初,我们通过 JDBC™ 让 WebSphere Application Server 直接更新 SLA 数据库,但我们发现这样做严重地影响了测试性能。现在,我们在测试运行的末尾检查 SLA 数据库,以确定所进行的事务的数量。

过程:在两个软件包中,我们都能够指定测试的重复次数,以及测试要运行的最长时间。每个测试都要不断地重复 10 分钟,最多运行 10,000 次(我们特意选择了一个在此时间段内不会达到的数字)。对于每个产品,整个过程持续了大约一个小时,因为我们对每个产品分别运行了 1 个、5 个、10 个、15 个、20 个和 25 个用户的负载。虽然对 WPT 的测试过程完全地脚本化了,但是 Linux 上的 Rational Performance Tester 还不支持批处理执行。推荐:因此,您可能希望依照我们运行测试时所使用的以下这些步骤:

  1. 重新启动 WebSphere Application Server 软件,运行 zipSeries。
  2. 使 SLA 数据库更新,以确保引入了先前所有的事务。
  3. 在测试之前,从 SLA 数据库中获得并记录事务的总数量。
  4. 在测试机上开始一个两秒钟间隔的vmstat 日志。
  5. 运行有让 X 个用户同时访问的压力测试。
  6. 使 SLA 数据库再次更新。
  7. 在测试之后,再次从 SLA 中获得总事务数量,然后与预测试总数进行比较。

注意:
来自 SLA 数据库的总事务包括浏览和购买事务。我们在电子表格中记录了这些数字,这是我们随后用来分析 vmstat 日志的东西。

通信路径。图 1例举了比较测试是如何运作的。它从测试机(运行 Rational Performance Tester 或 WPT)对 zipSeries 软件中的 SetRandom 进行访问开始。从浏览数据库中选择任意的一个名称,然后使用购买数据库进行购买。最终将 scraper 日志发送到 SLA 数据库,其中带有在最终结束于测试机上的事务统计数字。注意,不管正常的 zipSeries 操作是什么,为了测试,所有的数据库通信都是通过 JDBC,包括购买事务。

图 1. 比较测试是如何运作的
比较测试是如何运作的

Rational Performance Tester:使用定制代码特性中的 Web 服务客户端进行随机的作者名称搜索

数据池特性允许 Rational Performance Tester 在测试运行过程中测试向 Web 页面所输入的随机值。这个非常好的特性是 WPT 所缺乏的。该特性允许客户端随机执行,而不是让服务器像执行象 SetRandom 所做的功能。这可能潜在地释放了 WebSphere Application Server 上的资源,因为服务器不再负责确定随机名称。如我们前面所提到的,Rational Performance Tester 数据池的实现在我们的环境中有局限性。幸运的是,Rational Performance Tester 有另一个称为 定制代码的特性,该特性允许用户开发其自己的将数据注入到 Web 页面请求中的程序。我们创建了下面的两个测试作为 Rational Performance Tester 数据池的可选方法。

最初的想法是开发能够由随机作者名称直接查询浏览数据库的定制代码。我们能运行 Rational Performance Tester 很长时间,模拟对不同作者的许多搜索。然而,这将会生成大量 JDBC 开销,以及比数据库服务器所必需的更多的工作。因此,我们使用 JDBC 连接池,创建一个用来缓存来自于浏览数据库的名称,并运行于单独的 WebSphere Application Server 服务器上的 Web 服务。然后,我们开发作为该 Web 服务的客户端的 Rational Performance Tester 定制代码。

测试及度量类似于第一个测试,除了不记录对 Random 页面的访问,而记录对 Books 页面的访问,并搜索作者。该类型的搜索返回浏览数据库中与此作者相关的所有书名。在 Rational Performance Tester 中,我们能够指定在搜索页面请求的定制代码中替换哪个值。注意,该测试只构成了通过 WebSphere Application Server 的一次数据库事务,而先前的测试中有两次。该测试也没有退出会话。然而,由于我们在每个测试运行前重新启动了 WebSphere Application Server,所以这一点没什么关系。

通信路径。图 2例举了 Rational Performance Tester Web 服务测试是如何运作的。它从 Rational Performance Tester 定制代码从 Web 服务那里请求随机作者名称开始,然后在 zipSeries 站点中搜索该名称。事务被记录到一个文件中,最终发送到 SLA 数据库,然后到测试机。

图 2. Web 服务测试
图 2. Web 服务测试
图 2. Web 服务测试

Rational Performance Tester:使用 plain socks 客户端搜索随机作者名称

虽然 Web 服务客户端代码作为 Rational Application Developer 中的独立代码可以正确地工作,但是确定让 Rational Agent Controller 恰当地引入 J2EE 库所需的过程要花费我们一些时间。此外,对于只安装了 Rational Performance Tester 的用户来说,直接使用带有定制代码的 Web 服务不是可用的解决方案。

最后,我们注意到建立到 Web 服务的新连接是非常慢的,所以我们需要每次都重新连接需要获得新作者名称的 Rational Performance Tester。不存在将连接保持在定制代码中的现成的方法。因此,我们开发了 TCP/IP socket 客户端/服务器程序,作为对 Web 服务的代理。理论上,服务器会从同一个机器上运行,作为 Web 服务,并且保持对 Web 服务的连接。客户端会从定制代码内部可靠地工作,因为基础的 TCP/IP socket 包含于标准的 J2SE 库中。过程与先前的测试完全一样,尽管我们修改了定制代码,以使用 Web 服务代理客户端。

通信路径。图 3例举了 Rational Performance Tester Web 服务代理测试是如何运作的。它从 Rational Performance Tester 定制代码特性从 Web 服务代理那里请求随机作者名称开始,从 Web 服务那里取回一个名称。然后该名称在 zipSeries 站点中用于搜索。事务被记录在一个文件中,最终发送到 SLA 中,然后发送到测试机上。

图 3. Web 服务代理测试
图 3. Web 服务代理测试
图 3. Web 服务代理测试

Rational Performance Tester:扩展的运行评估

在本测试中,对照过程 1 和 3,我们用 30 个用户负载运行 Rational Performance Tester 19 个小时。扩展运行的测试有两个目的:看看 Rational Performance Tester 测试涉及的机器在扩展的使用中如何响应,以及确定如果将随机功能放在一个单独的机器上,在 zipSeries 服务器上节省了多少 CPU 时间。因此,我们为每个测试记录了本地及服务器资源。

测试结果

以下的六个表格展示了我们的发现:

  • Users 表示在 WebSphere Application Server 服务器上启动的测试软件的客户端数量。
  • Total Trans 是测试机在 10 分钟运行内所完成的事务数量(在Trans/Sec 列中显示的数字是一个比率)。
  • Tot. Mem 是这段时间内操作系统所使用的最大内存量(物理内存及交换区)。
  • Max CPU Time 是按秒计算的 CPU 使用时间的最大百分比(运行内核及非内核代码,包括 IO 等待时间)。
  • Avg CPU Time 是 CPU 使用时间的平均百分比。

注意: 这些统计数字是由我们在测试过程中运行的 2 秒钟间隔的 vmstat 日志生成的。

测试 1,Rational Performance Tester 和 WPT 的比较,以关于 Rational Performance Tester 的重大新闻作为结束:虽然承受了大量的资源压力,但它始终还是比 WPT 快。在最佳的情况下(最小的负载),Rational Performance Tester 比 WPT 多处理 236% 的事务。在最坏的情况下(最大负载),Rational Performance Tester 在相同的时间段内仍旧能够比 WPT 多处理 30% 的事务。

图 4. 表 1: 测试 1,WPT 的结果
测试 1,WPT 的结果
测试 1,WPT 的结果
图 5. 表 2:测试 1, Rational Performance Tester 的结果
测试 1,Rational Performance Tester 的结果
测试 1,Rational Performance Tester 的结果

资源需求与速度差别一样明显。作为将非常需要资源正确地分配给 Rational Performance Tester 操作,在 Rational Performance Tester 没有运行的时候,我们使用同样的 10 分钟及 2 秒钟间隔的记录方法。表 3 显示,在重新启动,加载 X11™,并启动 Rational Agent Controller 之后,资源情况是类似的。

图 6. 表 3:不运行 Performance Tester 测试(控制)时的系统资源
表 3:不运行 Performance Tester 测试(控制)时的系统资源

在不运行测试的情况下,不存在许多活动。料想在空闲时,Rational Performance Tester 使用了几百兆内存。幸运的是,除了启用完整记录功能,在负载较重的情况下,内存消耗没有大量增加。

推荐: 我们建议对工作时间测试运行使用至少一台专用的机器。在我们的环境中,对于 WPT 测试,我们已经有一台这样的机器了,将来我们还计划将其用于 Rational Performance Tester。TRational Performance Tester 快速运行测试的能力,对重视测试站点完整性的人来说是一个明显的优势。

剩下的测试比较了对 Rational Performance Tester 的各种操作性策略。我们还以 30 个用户的负载运行这些测试,以确定性能是否会随着附加的用户而持续增加。对于测试 2 和 3,我们发现对于我们的硬件 25 个用户是最佳的负载。

测试 2 度量在搜索通过 Web 服务检索到的随机作者名称时 Rational Performance Tester 的性能。性能是一个常量,但是总的来说,是我们所执行的所有测试中最慢的,并且消耗最多的本地内存。

图 7. 表 4:测试 2 的结果
表 4:测试 2 的结果
表 4:测试 2 的结果

我们相信为每个名称请求建立新的 Web 服务的开销是导致事务发生率接近常量的瓶颈。然而,该方法的好处是其提供了无限的随机数据,并且不需要在服务器上运行额外的软件。

注意:
值得强调的是,瓶颈是我们在定制代码中实现解决方案的方法所导致的,因此,这不完全是 Rational Performance Tester 的问题。

当使用定制代码特性时,您必须特别注意使用不会过渡增加测试服务器上的工作负载的高效技术。然而,为了直接使用 Web 服务,如何使定制代码更有效对我们来说是不明显的。这就是为什么我们感觉测试 2 和测试 3 是有价值的过程,而放入本报告中。

测试 3 类似于测试 2,因为它使用了 Web 服务来检索随机名称,它在 Rational Performance Tester 和 Web 服务之间使用了代理来保持 Web 服务连接的持续。在大多数情况下,测试 3 几乎两倍于测试 2 的比率。

图 8. 表 5:测试 3 的结果
表 5:测试 3 的结果
表 5:测试 3 的结果

我们知道测试 1 和测试 3 以不同的方式运作,我们不能在这两者之间进行一致的比较。然而,考虑这一有趣的观察结果:测试 1 调用 WebSphere Application Server 上的 SetRandom。SetRandom 在同样的例程中有意地立即执行两个事务。因此,对于测试 1,Rational Performance Tester 进行一个单元的工作来完成两个事务,但在测试 3 中,进行一个单元的工作来完成一个事务。如果我们将测试 3 中 Rational Performance Tester 所完成的事务加倍,那么我们会注意到它比起测试 1 中的结果会好,并且对于轻负载会好的多。推荐: 因此,我们相信如果您需要对用户端无限制的随机,使用代理来缓存 Web 服务是可行的方法。

图 9 显示了测试 1 到 3 的主要结果。

  • 测试 1 显示了第一个测试的 Rational Performance Tester 结果,而 WPT 显示了第一个测试的 WPT 结果。
  • 测试 2 和测试 3 是 Rational Performance Tester 对于两个测试的分别结果。
图 9. WPT 和 Rational Performance Tester 事务发生率的比较
图 9. WPT 和 Rational Performance Tester 事务发生率的比较
图 9. WPT 和 Rational Performance Tester 事务发生率的比较

表 4 再次显示了与 WPT 相比 Rational Performance Tester 有多么的快。即使 Web 服务 Rational Performance Tester 测试比较轻负载的 WPT 还快,测试 3 的 Web 服务代理方法也是较好的方法。

在测试 4 中,我们想要确定,如果名称随机化功能成为测试机的责任,那么不运行应用程序的 CPU 时间是多少。我们发现,当 CPU 不处理随机操作时,其对于 zipSeries 服务器的平均使用时间下降大约 15%。我们感到非常高兴的是 Rational Performance Tester 能够在不出任何问题的情况下运行更长的时间。结果显示于表 6中,此处test 表示关于运行 Rational Performance Tester 的测试机的统计数字,zip 表示关于运行 zipSeries 书店的机器的统计数字。

图 10. 表 6:测试 4 的结果
图 10. 表 6:测试 4 的结果
图 10. 表 6:测试 4 的结果

注意,当不进行名称随机操作时,zip 机上节省下来多么少的内存 —— 至多,大约 33 MB。因此,执行随机操作本身占据很少的额外内存。除非缓存大量数据是关键的,去掉随机操作的好处是双重的:提高软件模块性,释放服务器上的 CPU 时间。尽管如此,添加的定制代码牵制了测试机上的更多资源,尽管比起 zip 机所释放的资源来说没有那么多。

关于未来过程的结论及决定

总体上,我们为 Rational Performance Tester 的能力所感动。尽管它比 WPT 消耗更多的本地资源,但是它在同一个时间段可以完成更多事务。定制代码特性对于减轻在主 WebSphere Application Server 机器上进行工作是非常有用的。它所拥有的同时运行不同测试的能力允许我们合并测试。因为 Rational Agent Controller 可以将测试分配到多台机器上,所以我们能够更容易地分析发源自不同位置的通信量将如何受到影响。因此,Rational Performance Tester 包含几乎 WPT 中我们所喜欢的所有的特性,加上一些强大的额外特性。虽然安装要花费一些时间,但是很简单。除了更新,在安装之后,Rational Performance Tester 不再需要进行配置。图形用户界面使基础功能的学习曲线很柔和。

假设我们对 Rational Performance Tester 很满意,我们计划全部采用它进行测试。我们将修改 zipSeries 软件上的 SetRandom 方法,以使用随机名称 Web 服务。Web 服务本身需要改进。如果我们决定对其进行扩展,以覆盖所有与浏览相关的功能,那么我么将考虑使用基于 DADX 的 Web 服务。如我们已经提到的,Rational Performance Tester 可以允许我们合并及组织某些类型的测试,并且,当它支持 Linux 上的 cmdlineexecute 插件时,我们能够移植一些基于 WPT 的测试脚本。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=236290
ArticleTitle=使用 IBM Rational Performance Tester 对一个模拟在线书店进行压力测试
publish-date=06252007