针对高可见性项目的性能测试挑战
　　一个金融机构的近期项目需要交付一个中间件基础设施，用于支持增长的应用程序列表，这些应用程序需要访问企业的核心金融系统。该体系结构的方向是要求所有的核心金融系统请求都经由该中间件解决方案，该方案使用基于 xml 的 ifx 消息标准。图 1 显示了与第一个应用程序有关的中间件基础设施（以粗体显示），以及未来的应用程序和后端系统（以灰色显示）。
　　
　　图 1. 待测试的解决方案
　　　
　　要使得该高可见性项目获得认可，必须演示在各种负载之下的最佳性能。这对于响应时间敏感的客户来说尤为重要，例如联络中心的 crm 应用程序。另一个需要考虑的问题是，当新的应用程序出现在中间件的“前面”和“后面”时（图 1 中显示了一个位于中间件“后面”的企业和消费者信用卡服务系统的未来实现），需要重用已选择的性能测试方法。
　　
　　无用户接口
　　指定使用中间件基础设施的第一个应用程序是存款处理应用程序，它预定在中间件项目完成之后实现。这意味着测试团队不得不在没有用户接口可以准备和提交中间件请求的情况下模拟生产负载。
　　
　　有限预算
　　金融机构并没有合适的工具集来支持中间件性能测试。因此，这里的挑战是确信地报告已观察到的中间件性能特性，同时将用于工具和准备工作的预算保持最小。
　　
　　使用 jmeter 救急
　　通过研究各种可用的开放源代码测试工具，发现 apache jmeter 可以支持中间件性能测试需求。 jmeter 提供一个基于 gui 的应用程序，用于设计和执行多种可重用的测试计划。jmeter 还支持以 xml 格式捕捉测试结果，用于测试后的统计分析。这两个特性帮助测试团队开发和文档化可重复的测试结果，从而满足“高可见性”的挑战。
　　
　　许多开放源代码的测试工具是设计用于测试 web 站点的，并期望测试能够模拟用户与一个或者多个页面或表单的交互。因为在测试中间件解决方案时，应用程序的 web 接口并不可用，所以已选择的工具必须在没有浏览器交互的情况下支持基于 xml 的消息。jmeter 的 soap/xml 请求组件满足该要求。
　　
　　最后，由于 jmeter 是 apache 软件基金会的产品，这个事实意味着该项目并不要求支付商业测试工具的许可证费用，从而满足“有限预算”的条件。
　　
　　设计测试脚本
　　性能测试的目标是，在各种并发负载条件下提交随机选择的、预先定义的、ifx 编码的请求消息，并记录接收到 ifx 编码的响应的耗用时间（elapsed time）。下面五个 jmeter 测试计划组件用于准备性能测试脚本。
　　
　　测试计划
　　这是用于测试的主要组件。在这里，测试名是根据项目的命名约定指定的。同时，选择 functional test mode，以便在由 view results tree 管理的测试结果中捕获完整的 ifx 编码的响应。
　　
　　图 2. jmeter 测试计划
　　　
　　http header manager
　　该组件用于指定中间件所需要的 http 头的值。发送到中间件的每个 ifx 编码的请求都将包括这些 http 头的值。
　　
　　图 3. jmeter http header manager
　　　
　　thread group
　　该组件按照测试计划的要求进行重复，以模拟一个特定数目的并发用户。例如，模拟 5 个并发用户，需要指定 5 个 thread group。
　　
　　 4. jmeter thread group
　　　
　　注意，thread group 组件具有一个标签为 number of threads 的域，用于控制与一个 thread group 相关联的线程数目。由于每个 thread group 具有一个惟一的随机选择的 ifx 编码的请求集合（请参阅下面的 soap/xml-rpc request），因此决定将每个 thread group 限制为一个线程。如果对于一个或者多个 thread group 指定多个线程，那么相同的消息集合将会被发送多次，这将违背随机选取准则的目标。
　　
　　soap/xml-rpc request
　　针对每个 thread group 所发送的期望数目的 ifx 编码请求，重复该组件。实际的 ifx 编码的请求是在该组件中指定的。
　　
　　图 5. jmeter soap/xml-rpc request
　　　
　　view results tree
　　该组件服务于两个目的。当测试执行时，该用户接口显示消息被发送和接收的测试过程。而且，该组件将测试结果写入到一个文件，用于测试后的分析。
　　
　　图 6. jmeter view results tree
　　　
　　jmeter 测试计划被设计用于模拟多种并发用户负载，从单一用户到最大为 80 个并发用户。对于所有的测试计划，上面所描述的五个组件以一致的方式进行部署，从而简化了性能测试的执行。
　　
　　构建测试脚本
　　一旦已经确定所需的 jmeter 组件并且已经构思好一个通用的测试计划设计，就必须构建测试脚本了。幸运的是，system integration test （请参阅 参考资料）中有超过 300 个 ifx 编码的模型请求消息和相关的测试数据可以重用。相应的挑战是准备测试脚本可以发送多达 8000 个（对于 80 个线程，每个线程 100 个）随机选择的请求消息。这些消息是随机选择的，从而更好地接近生产条件的稳定状态，生产条件下没有一个请求类型可能会比其他类型提交得更多。单独使用 jmeter 用户接口，将意味着手工剪切和粘贴消息到 8000 个 soap/xml-rpc request 中。为了使得该任务进一步复杂化，根据金融机构的 ifx 规范，每个请求还要求惟一的 rquid。
　　
　　自动创建测试脚本
　　正如已经提到的，该项目的性能测试方法将针对未来的中间件版本进行重用。因此，测试团队投入一些精力准备一个 java 应用程序，用于根据指定的参数输出 jmeter xml 编码的测试脚本。该 java 应用程序称为 scripter，它可以准备一个性能测试脚本，该脚本具有指定数目的线程并且每个线程具有指定数目的 ifx 编码的消息，由应用程序随机选择。ifx 编码的消息来源于一个消息集合，该集合在 scripter 的属性文件所指定的目录中提供。
　　
　　从本文 参考资料 小节中的链接，您可以下载 scripter java 应用程序的源代码和用法说明。
　　
　　执行测试
　　jmeter 安装在一个 双通道的 ibm eserver™ xseries® 360 服务器上，该服务器具有 2 gb ram 并且运行 windows® 2000。图 7 显示测试配置。
　　
　　图 7. jmeter 性能测试配置
　　
　　当测试执行时，ifx 编码的响应被记录，从而可以分析包含在中间件响应中的捕获到的 mq time 和 total time 度量。还可以分析 jmeter 观察到的 jmeter time，尽管该数字还包括在中间件和 jmeter 之间的网络延迟。
　　
　　测试团队执行三个性能测试周期，在前两个周期之后通过修改和配置调整从而改进应用程序的性能。
　　
　　分析结果
　　测试团队使用 microsoft® excel 电子数据表来导入测试结果，并且针对上面描述的耗用时间度量执行统计运算。然后，结果被图形化，从而显示该应用程序对于大多数测试条件提供的次秒级（sub-second）响应性。
　　
　　获得的经验
　　总的说来，jmeter 作为该项目的性能测试工具是一个极好的选择。下面所获得的经验提供另外的细节。
　　
　　jmeter 满足我们的需要
　　jmeter 易于安装并且具有中等的认识复杂度（请参阅下一条经验）。所选择的 jmeter 组件针对所有的性能测试脚本提供了一个公共的结构。测试结果的 xml 编码输出对于测试后分析是一个方便的特性，因为该选项捕获了包含在 ifx 编码的应答消息中的性能统计。
　　
　　jmeter 用户应该具有技术能力
　　为了正确地准备性能测试脚本，脚本开发人员必须很好地理解使用 http 和 xml 协议的分布式应用程序。商业用户可能发现难以使用各种 jmeter 组件的技术规范。
　　
　　创建大的脚本可能需要额外的自动化处理
　　我们的性能测试特性（随机的消息选取，并发性，以及包含在每个 ifx 编码的请求中的惟一值）要求一个自动化的方法产生测试脚本。幸运的是，测试团队具有足够的 java 技术能力使得该任务自动化。对于具有类似需要的人，本文的末尾提供了该应用程序。
　　
　　如果时间（和能力！）允许的话，团队还可以开发一个新的符合该项目需要的 jmeter 组件，并且将该组件提交给 apache 组织。
　　
　　定制的性能度量可以帮助确定问题
　　jmeter 应用程序可以测量在传输 ifx 编码的请求和接收 ifx 编码的应答之间的耗用时间。然而，该度量并不提供有关该分布式中间件解决方案所存在的潜在瓶颈的内部信息。中间件开发团队提供另外的性能度量，将用于主机通信、消息分析的耗用时间与用于事务处理的中间件耗用时间隔离开来。这些度量作为 xml 注解包含在 ifx 编码的应答中。