平均分 (0个评分)您能将任何这些陈述联系起来吗：
- 目前我们还未做任何性能测试。我们想做，但不确定从何处入手。
- 我们的应用程序运行得很好，但在开发团队发给我们一个更新版本用于部署后，我们在服务器上体验到了高得多的 CPU 使用率。高 CPU 使用率缘何而来？
- 我们将应用程序从 2.0 版迁移到了 3.0 版，现在响应时间是以前的 3 倍。是什么导致了这些延迟？
- 我们的应用程序需要在接下来的 3 个月支持超过 40% 的用户。除了简单地向集群添加更多机器，我们还能为此准备什么？
这些陈述代表着非常常见的场景，所以如果听到任何这些熟悉的声音，那么您并不孤单。本文的目标是解决这些类型的情景，提供一些有关执行测试的基本过程和可用的适用工具的一些最佳实践建议。总体来讲，这里讨论的主要主题将帮助您：
- 编写有用的性能测试案例。
- 驾驭不同的负载量以降低和提高利用率。
- 激励关键性能和系统指标。
- 与应用程序开发周期并行地执行性能测试。
- 使用 IBM Health Center 等工具查找性能瓶颈。
- 与开发团队合作修复瓶颈并重新度量。
曾几何时，性能测试被视为在部署到生产之前才做的事情。它常常只有非常少的工作量，没有分配足够的时间来识别和修复最终将在生产环境中出现的真实问题。要执行合适的性能测试，一种普遍推荐的方法是实现 性能生命周期，其中性能测试计划为开发工作的一部分，集成了迭代式测试作为新功能。这能够在将所有功能部署到生产环境之前，就能够很早地识别出瓶颈，并解决这些问题。
合适的性能测试的另一个好处是有机会调节环境（操作系统、JVM、应用服务器、应用程序和数据库等）以实现最大性能。只有通过合适的性能测试，才能调节所评估的参数以确定它们是否提供了任何价值。许多用户基于开发人员建议来设置 JVM 堆大小，不会调节其他任何参数，因为这被认为没有必要。您可能会很惊奇，只需执行一些简单的调节步骤，即可将为调节的环境所需的硬件量减少一半。本文将证明这一点。
使用一些简单的调节过程，DayTrader 性能基准测试应用程序可处理两倍于未调节环境的负载。这意味着相同数量的用户可能只需使用一半的可用硬件资源即可支持。想想这能够节省的成本。
除了在整个开发周期执行迭代测试和用于调节用途的测试优势，广泛性能测试的另一个主要优势是，能够对比不同应用程序和环境改变的结果。真实的性能测试会记录关键指标，使管理员能够洞察可能出现的问题（稍后将讨论）。回到上面的一种常见评论，许多用户在迁移到更新的应用程序版本时，都未准备好找出问题的根源，因为他们从未对以前的版本执行合适的性能测试或记录关键系统指标。缺少此工作，具有更糟的应用程序版本的测试服务器可能需要设置为一个对比点。有了此类型的数据，就可以容易得多地分析性能降级来自何处。
有两条基本的合适性能测试最佳实践，它们可总结如下：
- 改变用户（或客户端负载）数量。一个生产环境通常在一天之内具有不同数量的活动用户。质量测试可确保应用程序在小负载和峰值（例如黑色星期五）负载下良好地执行。这可能意味着请求之间的 “思考” 时间的更改和使用应用程序的活动用户数量的更改。这么做的一种最佳方式是对 1 位活动用户、2 位用户、4 位用户、8 位用户等执行测试。您稍后将看到此方法的实际应用。
- 记录关键系统和性能指标。应该为所有场景记录一些重要的指标。对于每次性能运行，要记录的最重要指标是：
- 吞吐量（每秒请求数）
- 响应时间
- 应用服务器机器 CPU 利用率 %
- 其他机器 CPU 利用率 %，如 Web 服务器、负载驱动程序和数据库（如适用）
只要使用了负载驱动工具，就可以看到吞吐量和响应时间指标。对于 CPU 利用率、内存利用率、磁盘 I/O 和网络流量指标，可以使用 Linux? 或 AIX? 上的 vmstat 或 nmon 工具进行查看，或者使用 Windows? 上的任务管理器进行查看。除了上述指标之外，记录所有系统级信息也很重要。这包括操作系统级别、活动核心数量、可用内存 (RAM) 量、“Java? 版本” 输出、WebSphere Application Server 版本信息，以及所有已应用的调节。记录所有这些指标使您能够迅速对比不同场景，即使对比的场景的测试时间已相隔两年。
许多用户没有可用于再现与测试环境大小相同的生产环境的硬件。在这些情况下，推荐的方法是基于可用的资源来扩展性能测试。例如，假设一个生产环境包含 10 个物理机器，每个机器运行两个 WebSphere Application Server 实例。如果一个物理机器都可用于性能测试工作，那么此机器可设置为与生产机器尽可能相同，并且性能测试中使用的负载将大约为预期生产工作负载的 10%。最终，应该扩展性能测试，以再现完整的生产环境。这样，其他流程（比如数据库和 LDAP）的负载也会进行测试。
执行性能测试和查找应用程序瓶颈的第一步是编写有用的测试案例。结果和分析取决于用于生成它们的测试案例，所以这一步不应轻率地执行。与对所有用户都将使用的代码路径执行压力测试相比，对用户仅花了不到 10% 的时间的应用程序代码路径执行压力测试的效果差得多。首先专注于最流行的代码路径，然后为更少利用的代码路径构建您自己的测试。在这里花一些时间真正创建一个模拟实际用户流量的高质量测试案例。这篇 developerWorks 文章 是帮助开始编写性能测试案例的一个不错的资源。
定义了测试案例概念之后，您将需要通过一个性能负载驱动工具将它应用于实践。有许多负载驱动程序可供选择，包括 IBM Rational Performance Tester 和 Apache 的开源 Jmeter。本文将使用后者。
如果您之前阅读过 developerWorks 上的任何性能文章，那么您很可能已听说过 “Trade” 或 “DayTrader” 基准测试。Apache DayTrader Performance Benchmark Sample 应用程序模拟了一个简单的股票交易应用程序，它让用户登录/注销、查看他们的投资组合，查找股票报价，购买和销售股票，并管理帐户信息。DayTrader 不仅可用作功能测试的出色应用，还提供了一组标准的工作负载集来描绘和度量应用服务器和组件级性能。
DayTrader 构建于一组核心的 Java EE 技术之上，包括用于表示层的 Java servlet 和 JavaServer? Pages (JSP)，以及用于后端业务逻辑和持久性层的 Java 数据库连接 (JDBC)、Java Message Service (JMS)、Enterprise JavaBeans (EJBs) 和消息驱动的 bean (MDB)。图 1 给出了该应用程序架构的总体概述。
图 1. DayTrader 应用程序概述
IBM 发布了一个样例 DayTrader 包 供下载，它包含 DayTrader 应用程序和所需的部署描述符，可以将它们安装在 WebSphere Application Server V7.0 或更高版本上。
在此示例中，将 DayTrader 样例应用程序部署成了 WebSphere Application Server V8.5 的一个基本实例。一个简便的 DayTrader 功能是 Configuration 选项卡下的 TradeScenarioServlet 链接。它会链接到模拟一群 Web 用户的一个 servlet，为每个访问该 servlet 的用户随机生成具体的 DayTrader 操作。（例如，一个用户可查看他的投资组合、一个用户可执行股票购买操作，一个用户可查找一个股票报价等）。这可确保 DayTrader 中的每个主要操作都会在测试期间执行，因为它是随机的，所以一段时间后每个操作都应执行大体相同的次数。有许多参考资料介绍了如何使用 JMeter 编写非常复杂的性能测试，其中可为每个操作指定使用的准确次数和使用顺序，但出于本文的用途，测试案例将会保持相对简单并使用此 TradeScenarioServlet。
设置 Jmeter 并运行它来执行性能测试：
- 安装 Jmeter。指向您的 java 目录，使用
jmeter.sh或jmeter.bat脚本从 <JMeter_Home>/bin/ 目录启动 JMeter。您应看到一个类似图 2 的面板。
图 2. JMeter 默认试图
- 右键单击 Test Plan 并转到 Add > Thread Group。这是您定义要处理其负载的用户数量的地方。对于初学者，使用以下值（参见图 3）：
- 线程（用户）数量：
1 - 循环数量：Forever
图 3. JMeter Thread Group 视图
- 线程（用户）数量：
- 右键单击您刚创建的线程组，转到 Add > Sampler。一个抽样器 (sampler) 定义您希望处理的负载类型。有针对 HTTP 请求、JMS 请求、Web 服务消息等的抽样器。JMeter 用户手册记录每个可用的抽样器。因为 DayTrader 支持基于 Web 的流量，所以此示例使用 HTTP Request。依据您的环境填写主机名、端口和路径的值（参见图 4）。
图 4. HTTP 请求
- 右键单击您刚创建的 HTTP 请求并选择 Add > Timer。计时器添加请求之间的 “思考时间”。这模拟一个用户单击一个页面，然后暂停阅读页面上的一些信息，最后发出另一个请求。您可选择许多预定义的计时器，具有从常量固定计时器到高斯或泊松分布式计时器的不同复杂度。JMeter 用户手册 记录每个可用的计时器。对于这个简单示例，仅使用 5 ms 的 Constant Timer。
- 右键单击该线程组并转到 Add > Listener > Summary Report。这将显示测试运行时的响应时间和吞吐量结果。
- 将设置保存到一个文件，以便您可在以后再次加载它们。
在启动负载驱动工具之前，始终要确保应用程序兼容一个浏览器。准备好后，单击绿色箭头或单击 Run > Start。JMeter 现在应将一个客户端连接到您指定的服务器路径，在每个请求之间等待 5 ms。如果您单击 Summary Report，可以看到测试运行的结果。
您应会注意到，吞吐量在不断增长；这称为 “升温” 阶段。JRE 需要一些升温时间来加载所有类，让 JIT 执行一些优化。吞吐量最终将稳定，达到一个固定的数量（每秒发出或接受一些请求）。依赖于测试的复杂性，这个升温阶段可能持续 30 秒，也可能持续 30 分钟。
在测试运行时，打开一个终端（Linux 或 AIX）并运行 vmstat 5 来每隔 5 秒显示一次系统指标（参见清单 1）。
清单 1
[root@spice3 bin]# vmstat 5 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 8235164 104920 500956 0 0 13 11 44 154 8 5 86 0 0 0 0 0 8235164 104928 500956 0 0 0 3 8030 4987 6 1 93 0 0 1 0 0 8235040 104936 500956 0 0 0 3 7982 4944 5 1 94 0 0 0 0 0 8233116 104936 500960 0 0 0 6 8126 5020 7 1 92 0 0 0 0 0 8231068 104944 500960 0 0 0 6 7952 4939 6 1 93 0 0 0 0 0 8231316 104952 500960 0 0 0 3 7761 4819 5 1 94 0 0 Example vmstat output showing ~7% CPU utilization. |
如果使用 Windows，右键单击任务栏并选择任务管理器，然后选择性能选项卡。当 JMeter 中的吞吐量达到一个稳定值后，记录运行 WebSphere Application Server 的服务器和任何其他适用服务器上的 CPU 利用率，然后单击红色停止标志或 Run > Stop 停止 Jmeter 测试。JMeter Summary Results 视图类似于图 5。
图 5. JMeter Summary Report 视图
在一个电子表格中，记录吞吐量结果（93.9 个请求/秒）和平均响应时间结果 (4 ms)。如果您希望更详细的信息，那么 Min、Max 和 Std. Dev. 响应时间也很有用。
记录所有结果后，选择 Run > Clear 来清除 Summary Report 结果。这会介绍对单个用户的测试。现在将用户数量依次增加到 2、4、8 等，并重复上述步骤。每次添加更多用户时您都应观察到吞吐量增长。最终，您会观察到吞吐量停止增长，甚至可能开始下降。达到平稳状态（以及可能下降）时，测试即可停止。
完成上述步骤后，您应得到一个类似图 6 的电子表格。（这些具体的结果高度依赖于 DayTrader 应用程序和运行此测试的环境。您的实际结果可能有很大不同。）
图 6. Test Results – Table 视图
拥有这样的表列格式的原始数据很有用，但以图形格式查看结果也很有用。可视化结果的一种最佳方式是使用 XY 散点图。绘制一个图表来描绘结果，会使趋势的识别容易得多。图 7 描绘了吞吐量和 WebSphere Application Server CPU % 与客户端数量的关系。
图 7. Test Results – Graph
上面的图 7 显示了一些有趣的特征。首先，可以看到吞吐量曲线和 CPU % 曲线非常接近。第二，可以看到应用程序吞吐量从 1 个客户端近线性地扩展到 500 个客户端。这是想要的结果。但是，在 500 个客户端到 1,000 个客户端之间的某个点，吞吐量的增速开始放缓。（这时可使用 500 到 1,000 之间的用户负载来执行更多测试，以查找发生此增速放缓现象的准确位置。）将客户端负载增加到 1,000 个客户端以上不会改进总体应用程序吞吐量。这就是所谓的饱和点。这是一个重要的值，必须在性能测试中找到。饱和点告诉您，您已达到此应用程序、调节、配置和环境的最大容量。添加超过此点的更多用户只会增加客户端响应时间，不会增加总体应用程序吞吐量。要获得超过此点的更高性能，必须执行应用程序代码更改、调节更改或环境更改。
这种类型的测试和分析是大小调整和容量规划讨论中主要主题。只有通过识别饱和点，您才能准确估算支持一个生产环境所需的总容量。常常有人会说，“我需要在此环境中支持 10,000 个用户”，然后对该客户端负载运行测试。通常，此方法会在一个或多个组件中引起各种各样的超负荷情形，这些情形可能在 WebSphere Application Server 中，也可能在其他基础设施组件（网络、数据库等）中。一种更高效的方法是确定使用单个应用服务器可获得何种客户端负载和吞吐量，然后基于此信息继续执行运行时和应用程序调节。调节完成后，可将注意力转向确定满足可伸缩性需求需要多少应用服务器流程和流程服务器。
将一个新测试保存在 JMeter 中，使用您找到的线程（用户）数作为饱和点。这可用作一项快速测试，以对比您对应用程序或环境执行更改时的性能，而无需再次执行完整的可伸缩性测试。这不是说您不应再执行可伸缩性测试，但对于在 CPU 未充分利用的更低负载上不会显示出任何不同的更改，运行饱和点上的负载是对比这些更改的一个不错地方。一种不错的做法是对次要应用程序或调节更改运行饱和点负载，对主要应用程序或环境更改重复完整的可伸缩性测试。
以上各节是执行任何真实分析工作的准备条件。您必须首先理解如何生成可重复的性能结果，才能查找瓶颈和性能改进。现在您已准备好查找改进了，应使用以下两个性能工具来开始分析：
- IBM Tivoli? Performance Viewer
Tivoli Performance Viewer（在管理控制台中）是一个监视 WebSphere Application Server 的非常有用的工具。这篇文章 重点介绍了使用 Tivoli Performance Viewer 最优地调节环境的好处。采用相同的方式，Tivoli Performance Viewer 可用于快速检查是否有任何可通过调节轻松删除的瓶颈。
以下是一些开始使用 Tivoli Performance Viewer 的简单步骤：
- 使用比确定为饱和点的用户数量重新启动 JMeter 负载。
- 登录到管理控制台并选择 Monitoring and Tuning > Performance Viewer > Current Activity。单击您希望监视的服务器，然后展开 Performance Modules。这将显示一组可供查看的性能模块。
- 您的应用程序特征将确定其中哪些模块最有必要查看。对于 DayTrader 示例或任何其他基于 Web 的流量，启动 Thread Pools > WebContainer 模块。勾选该复选框，单击顶部的 View Module 按钮。这将显示一个类似于图 8 的图表，在 JMeter 测试继续运行时，每隔 30 秒自动填充更多数据。
图 8. WebContainer PMI 数据
此示例显示，WebContainer 线程池大小为 50 个线程，其中大约 32 个正在使用。这告诉您，WebContainer 线程池大小不是当前工作负载下的瓶颈。如果活动数量在 45-50 之间波动，那么 WebContainer 线程池大小可能是一个瓶颈。在该情况下，可能最好增加 WebContainer 线程池大小，重复该测试以查看性能是否改进。如果吞吐量确实增加了，您可能希望再次运行湾镇的可伸缩性测试，以重新建立基准。
- 对其他适用于您的应用程序的模块继续重复第 3 步。对于 DayTrader 这样的事务应用程序，应查看的另一个模块是 JDBC Connection Pool 信息。展开 JDBC Connection Pools > 您的 JDBC 驱动程序），选择您的数据源 JNDI 名称。单击 View Module 按钮以显示一个类似图 9 的图表。
图 9. DataSource PMI 数据
此图表描绘了一些与默认选择不同的选项。PoolSize、FreePoolSize 和 WaitingThreadCount 都是很有用的指标，可查看它们来确保您的连接池不是争用来源，WebContainer 线程没有排队等待连接数据库。在上面的示例中，连接池大小固定为 50 个连接（这是一项调节设置）。空闲池大小在 20 上下波动，这意味着一次有大约 30 个连接是活动的。从这些信息得到的是一个 Waiting Thread Count 0，表明没有 WebContainer 线程在等待连接数据库。这可确认 JDBC 连接池大小不是瓶颈。如果空闲池大小为 0，并且等待的线程数量大于 0，那么您可能希望使用更高的连接池大小重复测试。
- IBM Monitoring and Diagnostic Tools for Java - Health Center
IBM Monitoring and Diagnostic Tools for Java - Health Center（以下简称 Health Center，它包含在 IBM Support Assistant 中）工具是在 WebSphere Application Server 进程上执行详细的性能分析的推荐工具。Health Center 提供了有关服务器性能的丰富知识，包括以下信息：
- 内存使用
- 垃圾收集统计信息
- 方法级探查
- 锁争用分析。
Health Center 是 IBM Support Assistant (ISA) 中的一个工具，可免费下载。请确保将 ISA 安装在一个不同于应用服务器机器的机器上，否则 Health Center 将占用应用服务器进程中的资源，您的结果也可能不太准确。Health Center 可在一种交互式模式下运行，也可在一种 “无头” 模式（其中的信息保存在一个文件中供以后查看）中运行。对于此示例，您将使用交互式模式。
启动 Health Center：
- 重新启动您希望使用一般 JVM 参数
-Xhealthcenter获得其详细信息的 WebSphere Application Server 进程。 - 启动 ISA。当加载时，选择 Analyze Problem。（如果以前已完成此过程，您将需要告诉 ISA，您对 WebSphere Application Server 的工具感兴趣。）
- 选择 IBM Monitoring and Diagnostic Tools for Java – Health Center 并单击 Launch（参见图 10）
图 10. 从 ISA 启动 Health Center
- 将显示一个连接向导。单击 Next。指定应用服务器运行时使用的主机名或 IP 地址。在默认情况下，将使用端口 1972。如果有任何安全需求，可在这里指定它们，否则单击 Next。如果找到了主机名和端口，再次单击 Next，否则查明为什么连接无效。如果成功，Health Center 将类似于图 11。
图 11. Health Center 默认视图
- 最大化 Health Center 的屏幕并单击它，以了解它的功能。现在，您已准备好开始一些详细的性能分析了（接下来几节将进行介绍）。继续使用在您的饱和点上找到的用户数量重新启动 JMeter 负载。Health Center 将在新信息可用时动态地更新。让 JMeter 负载在您的升温阶段持续运行，然后再继续操作。
任何 Java 应用程序性能分析中的第一步始终应为分析垃圾收集统计信息。保持 Health Center 正常运行，这很很容易做到。
单击 Health Center 窗口中的 Garbage Collection 链接。将显示一个类似图 12 的视图。
图 12. Health Center – Garbage Collection 视图
对于入门级分析，首先应检查两件事：
- 左下角的 Analysis and Recommendations 部分提供了基于 Health Center 中内置智能构建的有用技巧和信息。这些技巧可能表示垃圾收集策略和堆大小建议，以及有关内存泄漏或 System.gc() 调用的观察值，等等。在图 12 中，该部分告诉您，gencon 是 DayTrader 的一个最优的 GC 策略，该应用程序似乎不会泄漏内存。这始终是一个不错的起点。
- 窗口底部的 Summary 面板包含您应关注的最重要的统计数据，从 “Proportion of time spent in Garbage Collection pauses” 开始。这项统计信息告诉您，您的应用程序由于发生垃圾收集而停止的时间比例。这个数字应尽可能低，理想情况下低于 2-3%。如果此数字为 10%，那么通过调节 JVM 堆大小和垃圾收集策略，可实现高达 10% 的吞吐量提升。如前所述，这个案例分析是一篇可帮助指导您执行调节过程的优秀文章。
其他一些能够帮助您查找您最感兴趣数据的技巧包括：
- 图 12 中的图表中的 X 轴显示自服务器启动以运行的时间。您可更改此值以绘制一天的图表。这可能对关联在一天某些时刻发生的活动有所帮助。X 轴可通过选择上下文菜单 > Change Units > X-Axis > Time 来更改。
- 您可剪切数据来消除预热期，以获得在正常活动条件下所发生事情的更准确视图。为此，选择 Data > Crop Data（以剪掉开始和完成时间）或者选择 Data > Reset Data 来清除截至此时刻的任何数据。
- 对于更详细的分析，单击 Samples by object 选项卡。这使您能够看到分配对象的故障、为每种类型分配的对象数量，以及的对象总大小的统计分析。甚至可以选择按包或对象名来搜索。图 13 显示了一个示例。基于这些结果，检查应用程序代码以查看是否可减少的 BigDecimal 和 BigInteger 的使用，这可能是一个不错的想法。
图 13. Health Center – Samples By Object 视图
保持负载驱动程序运行，单击 Profiling 链接。这将打开 Method Profiling 视图，类似于图 14。
图 14. Health Center – Method Profiling 视图
Method Profile 表显示了哪些方法正在使用大部分处理资源。这是整个 JVM 的视图，而不是您的具体应用程序的视图，所以这将包含数据库驱动程序、WebSphere Application Server 容器等的方法信息。查看此视图来从更大范围内了解服务器中所发生的事情，这很有帮助。与前面的垃圾收集分析一节中一样，一个最佳的起点的是 Analysis and Recommendations 部分。此面板将突出已发现使用了比其他方法多得多的 CPU 周期的任何方法。在上面的示例中，技巧表明没有明显的优化方法，因为所有周期都是均匀拆分的。如果这里显示了一个或两个方法，那么应检查该方法的代码，以查看是否可执行任何优化，或者调用次数是否可以减少。
为了更深入研究，您需要理解如何解释表中的数据。要获取帮助，请参阅 Health Center 文档，方法是选择 Help > Help Contents，然后向下滚动并展开 Tool: IBM Monitoring and Diagnostic Tools for Java - Health Center 图书。该文档表明：
具有更高的 Self (%) 值的方法描述为 “热的”，是优化的不错候选者。对这些方法的效率的细微改进可能对性能具有巨大影响。您可通过减少方法做的工作量或减少调用它们的次数来优化它们。接近表末尾的方法不太适合优化。甚至对它们效率的巨大改进也不可能会影响性能，因为它们使用的处理资源很少。
以下是对表中每列的描述：
表 1. 方法配置文件表
| 列 | 描述 |
|---|---|
| Self (%) | 在特定方法在堆栈顶部运行时采用的抽样百分比。此值是一个方法对处理资源的使用量的一个不错指标。 |
| Self | A graphical representation of the Self (%) 列的一个图形表示。更宽、更红的条块表示更热的方法。 |
| Tree (%) | 特定方法在调用堆栈中任何地方时采用的抽样百分比。此值表示处理此方法和它调用方法（子孙）的时间百分比。此值很好地指出了您应用程序中花费了最多处理时间的区域。 |
| Tree | Tree (%) 列的一个图形表示。更宽、更红的条块表示更热的方法堆栈。 |
| Samples | 在堆栈顶部运行特定方法时采用的抽样数量。 |
| Method | 该方法的完全限定的表示，包括了包名称、类名称、方法名称、参数和返回类型。 |
单击列标题，按升序或降序对所有这些列排序。理解这一点后，您可深入分析工作负载的性能特征。导航此表的一些有用技巧包括：
- 单击表中的一行将显示底部面板中显示执行该方法的完整调用路径。
- 在探查有效期间执行该方法时，将显示 Timeline 选项卡。这可能很有用，您无需关注配置文件中在之前（或许在升温期间）执行的某项功能，然后离开。
- Filter methods 文本框对搜索特定类和过滤配置文件的剩余部分很有用。这仅应用于下钻您应用程序的详细信息，以删除所有其他非应用程序类。作为一个示例，图 15 显示了按 “daytrader” 过滤的配置文件，因为所有 DayTrader 应用程序类的包名称中都包含 “daytrader”。这使您能够集中精力查找应用程序中使用资源最多的方法。
图 15. DayTrader 过滤的 Method Profile 视图
如果应用程序有一个特定的方法使用了大量 CPU 周期，然后 Health Center 将它标记为 Analysis and Recommendations 面板中一个不错的优化候选者。一个示例如图 16 所示。
图 16. 优化候选者示例
可花几天时间分析 Method Profiling 视图，以查找一个应用程序的性能改进。因为输出可保存到一个文件中，所以对比应用程序更改非常简单。应用程序开发人员可执行一项通过 Health Center 挂钩来部署和执行负载测试的更改，并且您可对比以前的配置文件信息，查看开发人员更改的方法增加还是降低了处理需求。
多线程应用程序需要同步（或锁定）共享资源，以使资源的状态保持一致。这种一致性可确保在一个线程读取另一个线程时，该线程的状态不会更改。
当在具有大量处理器的系统上部署的高负载应用程序中使用锁时，锁定操作可预防应用程序使用所有可用的处理资源。想象一下一个在 8 核机器上运行的应用程序，它的主要应用程序代码路径高度同步，所以一次只能执行一个线程。这可能使其他 7 个线程处于等待状态。
当在大型的多核（4 个以上）机器上运行时，锁分析对确保应用程序可扩展并利用所有可用的硬件资源至关重要。（如果应用程序在单核机器上运行，这里的分析可能没有太大价值。）Locking 透视图分析锁的使用，帮助识别应用程序或 Java 运行中阻止应用程序扩展的争用点。单击 Locking 链接后，应会显示一个类似于图 17 的面板。
图 17. Health Center – Locking 视图
初看起来，Moniors 视图可能很难使用和理解。但是，Health Center 文档详细描述了这个面板，以帮助您理解这些指标。表 2 描述了该表中的列的内容。
表 2. 监视器
| 列 | 描述 |
|---|---|
| % miss | 总 Get 或获取次数的一个百分比，对于这部分 Get 或获取，尝试在同步的代码上获取该锁的线程在获取锁之前必须阻塞。 |
| Gets： | 在充实期间，获取该锁的总次数。 |
| Slow： | 由于一个锁已被另一个线程拥有，请求线程必须为其等待锁的非递归锁获取的总次数。 |
| Recursive： | 递归获取的总次数。当请求线程已拥有监视器时，就会发生递归获取。 |
| % util： | 持有该锁的时间量除以接管输出的时间量。 |
| Average hold time： | 一个线程持有或拥有该锁的平均时间量。例如，同步的锁中花费的时间量（以处理器时钟单位计算）。 |
| Name： | 监视器名称。如果不知道名称，则此列为空。 |
该表列出了被充实的每个 Java 监视器。% miss 列是最初的关注点。高 % miss 表明受锁保护的同步化资源上发生了频繁的争用。这种争用可能阻止 Java 应用程序进一步扩展。
如果一个锁具有一个较高的 % miss 值，请查看 Average hold time 和 % util。一些技巧如下：
- 如果 % util 和 Average hold time 都很高，您可能需要减少在持有锁期间执行的工作量。
- 如果 % util 很高，但 Average hold time 很低，您可能需要使受锁保护的资源更加细粒度地将该锁分离为多个锁。
没有正确的工具和知识，开始执行性能测试和分析最初可能会很难。但是，本文表明，用户可以执行一些较简单的步骤来确保执行正确的性能测试，并确保应用程序瓶颈已消除，从而尽可能高效地执行应用程序。
即使 DayTrader 可能与您的应用程序不同，但本文中描述的测试性能和识别瓶颈的方法所发挥的作用是相同的。对较慢时期的小用户负载一直到峰值使用时期的高用户负载执行测试，这对理解您应用程序的特征至关重要。记录一些关键指标，用它们来对比应用程序或环境更改，这对理解性能降级的可能根源至关重要。最后，IBM Health Center 工具通过垃圾收集、方法探查和锁探查视图简化了性能分析，帮助您确保尽可能高效地执行应用程序。
学习
-
WebSphere Application Server 性能
-
IBM Monitoring and Diagnostic Tools for Java - Health Center Version 2.0
-
教程：Hello World：Rational Performance Tester 教程
-
图书：Java 网站性能分析
-
传统性能测试如何有效应用于 SOA 解决方案？
-
WebSphere 反向投资者：应对故障
-
案例研究：调优 WebSphere Application Server V7 和 V8 的性能
-
WebSphere 反向投资者: 调节 WebSphere 应用服务器时应适可而止
-
IBM developerWorks 中国 WebSphere 专区：为使用 WebSphere 产品的开发人员准备的技术信息和资料。这里提供产品下载、how-to 信息、支持资源以及免费技术库，包含 2000 多份技术文章、教程、最佳实践、IBM Redbook 和在线产品手册。
获得产品和技术
- 最受欢迎的 WebSphere 试用软件下载：下载关键 WebSphere 产品的免费试用版。
- IBM developerWorks 软件下载资源中心：IBM deveperWorks 最新的软件下载。
- IBM developerWorks 工具包：下载关键 WebSphere 最新的产品工具包。
讨论
- 加入 developerWorks 中文社区，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
- 加入 IBM 软件下载与技术交流群组，参与在线交流。
