Hello World: 使用 Rational Performance Tester 进行性能测试

第 7 页，共 11 页 文档选项 讨论 对本教程的评价 帮助我们改进这些内容

分析根本原因

至此，您已经成功地使用 Performance Tester 发现了应用程序中的性能问题。您问自己的下一个问题将是，“问题是由什么导致的？”要弄清这个问题，您将利用 Performance Tester 的 Root Cause Analysis 工具。在此部分中，您将重新运行测试，并运行附加的数据收集工具。附加的信息将帮助您确定，您是否面临了硬件或软件的问题，然后深入到性能瓶颈的根本原因。

启用资源监控

动画演示 您想要观看这些步骤的示范吗？ 显示 demo

1. 双击 Test Navigator 视图中的 AdventureBuilderLoadTest 调度。
2. 重新访问调度上的额外的执行控件：再次选择 Schedule Contents 的顶部节点。
3. 选择 Schedule Element Details 区中的 Resource Monitoring 选项卡。Resource monitoring 令 Performance Tester 从 Windows perfmon、Unix 或 Linux rstatd，或 Tivoli Monitoring 中记录任意的系统参数。
4. 选择 Enable resource monitoring。
5. 单击 Add New...，确定监控资源时所用的新服务器。注意到您可能需要滚动到 Performance Schedule 视图的右边，才能看到该按钮。
6. 在 Resource Monitoring 窗口中，输入 localhost 作为主机名。选择 Windows Performance Monitor。注意在此试用环境中，Web 服务器、应用服务器，和 Performance Tester 系统都运行在一个机器上：localhost。当然，这不是现实的情况。在真正的性能测试环境中，您可以定义可能作为应用程序或测试系统一部分的任意机器。
7. 选择 Resources 选项卡。几秒钟以后，您就能看到许多计数器。简单起见，除了 Memory > Pages/sec 和 Processor > % Processor Time 之外，取消所有的计数器选择。
8. 单击 OK，关闭 Resource Monitoring 窗口。

回页首

启用 Response Time Breakdown

1. 选择 Performance Schedule 的 Schedule Element Details 区中的 Response Time Breakdown 选项卡。
2. 选择 Enable collection of response time data。该项启用了 Performance Tester 的响应时间数据收集基础框架。
3. 由于您知道实际访问 Checkout 页的唯一测试是 PurchaseIslandAdventure，因此只选择该测试。
4. 在 Options 区中，将 Detail 级设置为 High。
5. 按下 Ctrl-S，保存计划。
6. 再次单击工具栏上的 Run 按钮。Performance Tester 如同以前一样启动了测试，但这次还启用了资源监控和响应时间故障收集。

回页首

分析资源利用数据

1. 当性能调度执行的时候，选择 Performance Report 上的 Resources 选项卡。这次，您将会看到您在计划中选择要收集的资源数据。
   
   图 21. Performance Report 上的 Resources 选项卡
   
   
   
2. 此处您看到的数据，虽然准确，但不是典型负载测试的真正代表。在该试用环境中，Performance Tester 负载生成、Web 服务器、应用服务器，和数据库服务器均运行在一台机器上。您通常会在应用程序的每个层次上跟踪资源。此外，您刚刚运行的负载测试的持续时间非常短。通常，性能测试会持续得更长，让系统达到稳定得状态。尽管如此，试用系统让您感受到了在性能测试过程中跟踪资源利用是多么容易。
   
   如果您感兴趣，那么您可以现在到 Response vs. Time Detail 选项卡上，右键单击图形，并单击 Add/Remove Performance Counters，将资源计数器覆盖到页面响应数据上。这将帮助您可视化地将资源利用中得峰值与页面活动关联起来。
3. 由于没有显示出 Adventure Builder 的性能问题与硬件相关，因此利用响应时间故障数据来查明是否与软件相关。

回页首

分析响应时间故障数据

1. 选择 Performance Report 的 Page Performance 选项卡。
2. 深入到 Checkout 页面背后的情节。右键单击针对 Checkout 页的图中的进度条，选择 Display Response Time Breakdown Statistics...。
3. 在 Selection Wizard 中选择 /ab/checkout.do URL 并单击 Finish。Response Time Breakdown Statistics 视图列出了 Adventure Builder 应用程序中服务器层所调用的方法。有各种各样分析该信息的方法。
4. 利用视图右上角中的 Layout 按钮切换到 Tree Layout 视图。
   
   图 22. Tree Layout 视图
   
   
   
   
   现在按照 递减的总时间排序，在列标题上单击两次 Cumulative Time。

回页首

查明问题的根本原因

标记为 rationaltd 的顶部节点表示机器。在此试用环境中，所有的在测系统及测试工具组件都运行在一台机器上。在现实的测试中，您可能会看到有多台机器列出。

标记为 J2EE/WebSphere... 的第二层节点是 WebSphere 应用服务器组件。从此处的信息，您可以快速看出消耗大部分总时间的 J2EE 小方面的类型是 Servlet。

1. 展开 Servlet 节点和 com.sun.j2ee.blueprints.waf.controller.web 包，及 MainServlet 类节点。它告诉您 MainServlet 类中的 doPost 方法的四次调用耗费了 42.113 秒。注意实际的值可能不同。
   
   图 23. MainServlet 的 doPost 方法的响应时间
   
   
   
2. 右键单击 doPost 方法并选择 Open Source。您知道吗 —— 您已经找到了性能问题的根源！
   
   图 24. 源代码中的 sleep 语句
   
   
   

回页首

	第 7 页，共 11 页