使用Apache JMeter测试WebSphere性能

了解如何部署Apache开源工具JMeter来测试基于IBM®WebSphere Application Server的中间件解决方案的响应能力。 性能测试旨在使用各种Interactive Financial eXchange（IFX）请求消息来模拟并发的不同用户负载。 如果您的项目的性能测试预算有限，并且您的解决方案采用XML消息传递，那么本文结尾处的经验教训可能会帮助您规划自己的性能测试策略。

高可见性项目的性能测试挑战

一个针对金融机构的最新项目提供了一个中间件基础结构，以支持不断增长的需要访问企业核心金融系统的应用程序列表。 体系结构的方向是要求所有核心金融系统请求都使用基于XML的IFX消息传递标准通过此中间件解决方案进行路由。 图1显示了与第一个使用它的应用程序（以粗体显示）以及将来的应用程序和将来的后端系统（以灰色显示）有关的中间件基础结构。

图1.要测试的解决方案

为了使这种高可见度的解决方案获得认可，它必须证明在负载下具有最佳性能。 这对于响应时间敏感的客户（例如联络中心的CRM应用程序）尤其重要。 另一个考虑因素是当新的应用程序在中间件“之前”和中间件之后都在线使用时，有必要重新使用所选的性能测试方法（如图1所示，该图显示了公司和消费者信用卡服务系统将来在中间件之后的实现）。中间件）。

没有用户界面

计划在中间件项目完成后实施第一个指定使用中间件基础结构的应用程序，即贷项处理应用程序。 这意味着测试团队必须设计测试来模拟生产负载，而无需使用用户界面来准备和提交中间件请求。

预算有限

该金融机构没有合适的工具集来支持中间件性能测试。 因此，挑战在于以最小的工具和准备工作预算来自信地报告观察到的中间件性能特征。

JMeter进行救援

对可用的开源测试工具的研究表明，Apache JMeter可以支持中间件性能测试要求。 JMeter提供了一个基于GUI的应用程序来设计和执行各种可重复使用的测试计划。 JMeter还支持以XML格式捕获测试结果，以进行测试后统计分析。 这两个功能帮助测试团队开发并记录可重复的测试结果，从而应对了高可见性的挑战。

许多开放源代码测试工具旨在测试网站，期望测试应该模拟用户与一个或多个页面或表单的交互。 由于在测试中间件解决方案时应用程序Web界面不可用，因此所选工具必须支持基于XML的消息传递，而无需浏览器交互。 JMeter的SOAP / XML请求组件满足了这一要求。

最后，JMeter是Apache软件基金会的产品，这一事实意味着该项目无需为满足有限预算条件的商业测试工具的许可费用提供资金。

设计测试脚本

性能测试的目的是在各种并发负载条件下提交预定义的IFX编码请求消息的随机选择，并记录经过的时间以接收预期的IFX编码的响应。 以下五个JMeter测试计划组件用于准备性能测试脚本：

测试计划

这是测试的主要组件。 根据项目的命名约定在此处指定了测试名称。 还选择了功能测试模式，以便在由“ View Results Tree组件管理的测试结果中捕获完整的IFX编码的响应。

图2. JMeter测试计划

HTTP标头管理器

该组件用于指定中间件所需的HTTP标头值。 发送到中间件的每个IFX编码请求都将包含这些HTTP标头值。

图3. JMeter HTTP标头管理器

线程组

根据测试计划的要求重复了此组件，以模拟特定数量的并发用户。 例如，为了模拟5个并发用户，指定了5个Thread Groups 。

图4. JMeter线程组

请注意， Thread Group组件具有一个标记Number of Threads的字段Number of Threads该字段控制与线程组关联的线程数。 由于每个线程组都有一组唯一的随机选择的IFX编码请求（请参阅下面的SOAP / XML-RPC请求），因此决定将每个线程组限制为一个线程。 如果为一个或多个线程组指定了多个线程，则同一消息集将被发送多次，从而违反了随机选择标准的目的。

SOAP / XML-RPC请求

对每个Thread Group要发送的IFX编码的请求数量重复此组件。 在此组件中指定了实际的IFX编码请求。

图5. JMeter SOAP / XML-RPC请求

查看结果树

该组件用于两个目的。 在执行测试时，此用户界面会在发送和接收消息时显示测试进度。 另外，该组件将测试结果写入文件以进行测试后分析。

图6. JMeter视图结果树

JMeter测试计划旨在模拟从单个用户到最多80个并发用户的各种并发用户负载。 对于所有测试计划，以一致的方式部署上述五个组件，以简化性能测试的执行。

构建测试脚本

一旦确定了所需的JMeter组件并构思了通用测试计划设计，就必须构建测试脚本。 幸运的是，系统集成测试（请参阅参考资料 ）提供了300多个IFX编码的模型请求消息和相关的测试数据，这些信息可以重复使用。 挑战在于准备测试脚本，该脚本可以发送多达8,000个（80个线程的每个线程100个）随机选择的请求消息。 消息是随机选择的，以更好地近似生产条件的稳定状态，在这种情况下，没有一个请求类型可以比另一个请求类型提交的更多。 仅使用JMeter用户界面，就意味着手动将消息剪切和粘贴到多达8,000个SOAP / XML-RPC请求中。 为了进一步使任务复杂化，根据金融机构的IFX规范，每个请求还需要一个唯一的RQUID 。

自动创建测试脚本

如前所述，该项目的性能测试方法将在将来的中间件版本中重用。 因此，测试团队投入了一些精力来准备Java应用程序，该应用程序将根据指定的参数输出JMeter XML编码的测试脚本。 Java应用程序Scripter可以准备性能测试脚本，该脚本具有指定数量的线程和每个线程指定数量的IFX编码的消息，由应用程序随机选择。 IFX编码的消息来自于由Scripter的属性文件指定的目录中提供的消息集。

您可以从“ 相关主题”中的链接下载Scripter Java应用程序的源代码和使用说明。

执行测试

JMeter安装在具有2 GB RAM且运行Windows®2000的双向IBM eServerxSeries®360服务器上。图7显示了测试配置。

图7. JMeter性能测试配置

在执行测试时，将记录IFX编码的响应，以便可以分析由中间件嵌入响应中的捕获的MQ时间和总时间度量。 还分析了JMeter观察到的JMeter时间，尽管该数字包括中间件和JMeter之间的网络延迟。

测试团队执行了三个性能测试周期，并在前两个周期后进行了修改和配置调整，以提高应用程序性能。

分析结果

测试团队使用Microsoft®Excel®电子表格导入测试结果，并根据上述经过时间指标进行统计计算。 然后将结果绘制成图表，以表明该应用程序为大多数测试条件提供了亚秒级的响应能力。

得到教训

总而言之，JMeter是该项目的性能测试工具的绝佳选择。 以下经验教训提供了更多详细信息。

JMeter满足了我们的需求

JMeter易于安装，学习起来中等复杂度（请参阅下一课）。 所选的JMeter组件支持所有性能测试脚本的通用结构。 测试结果的XML编码输出也是测试后分析的便捷功能，因为此选项捕获了IFX编码的回复消息中的嵌入式性能统计信息。

JMeter用户应具备技术技能

为了正确地准备性能测试脚本，脚本开发人员必须充分了解使用HTTP和XML协议的分布式应用程序。 商业用户可能会发现很难使用各种JMeter组件的技术规范。

创建大型脚本可能需要额外的自动化

我们的性能测试的特征（随机的消息选择，并发性和每个IFX编码请求中嵌入的唯一值）需要一种自动的方法来生成测试脚本。 幸运的是，测试团队具有足够的Java技术技能可以自动完成此任务。 本文的结尾为可能有类似需求的人提供了此应用程序。

如果时间（和才能！）允许，团队可能已经开发了一个符合该项目需求的新JMeter组件，并将其提交给Apache组织。

自定义性能指标可以帮助确定问题

JMeter应用程序可以测量从发送IFX编码的请求到接收到IFX编码的回复之间的经过时间。 但是，此度量无法提供对整个分布式中间件解决方案中潜在瓶颈的了解。 中间件开发团队提供了附加的性能指标，以隔离主机通信，消息解析所花费的时间以及事务处理所花费的中间件所花费的时间。 这些度量标准作为XML注释嵌入到IFX编码的答复中。

---

翻译自: https://www.ibm.com/developerworks/opensource/library/os-jmeter/index.html