此图表描绘了一些与默认选择不同的选项。PoolSize、FreePoolSize 和 WaitingThreadCount 都是很有用的指标，可查看它们来确保您的连接池不是争用来源，WebContainer 线程没有排队等待连接数据库。在上面的示例中，连接池大小固定为 50 个连接（这是一项调节设置）。空闲池大小在 20 上下波动，这意味着一次有大约 30 个连接是活动的。从这些信息得到的是一个 Waiting Thread Count 0，表明没有 WebContainer 线程在等待连接数据库。这可确认 JDBC 连接池大小不是瓶颈。如果空闲池大小为 0，并且等待的线程数量大于 0，那么您可能希望使用更高的连接池大小重复测试。
• 对有助于监视您的应用程序的任何其他性能模块继续执行此过程。WebSphere 反向投资者：应对故障
提供一个全面的统计信息列表，这些信息可能具有很高的监视价值。完成此练习后，您可转而使用 IBM Health Center 执行更详细的分析。
• 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 提供了有关服务器性能的丰富知识，包括以下信息：
1. 内存使用
2. 垃圾收集统计信息
3. 方法级探查
4. 锁争用分析。
• Health Center 是 IBM Support Assistant (ISA) 中的一个工具，可免费下载。请确保将 ISA 安装在一个不同于应用服务器机器的机器上，否则 Health Center 将占用应用服务器进程中的资源，您的结果也可能不太准确。Health Center 可在一种交互式模式下运行，也可在一种 “无头” 模式（其中的信息保存在一个文件中供以后查看）中运行。对于此示例，您将使用交互式模式。
启动 Health Center：
1. 重新启动您希望使用一般 JVM 参数
-Xhealthcenter
获得其详细信息的 WebSphere Application Server 进程。
2. 启动 ISA。当加载时，选择
Analyze Problem。（如果以前已完成此过程，您将需要告诉 ISA，您对 WebSphere Application Server 的工具感兴趣。）
3. 选择
IBM Monitoring and Diagnostic Tools for Java – Health Center
并单击
Launch（参见图 10）
图 10. 从 ISA 启动 Health Center
4. 将显示一个连接向导。单击
Next。指定应用服务器运行时使用的主机名或 IP 地址。在默认情况下，将使用端口 1972。如果有任何安全需求，可在这里指定它们，否则单击
Next。如果找到了主机名和端口，再次单击
Next，否则查明为什么连接无效。如果成功，Health Center 将类似于图 11。
图 11. Health Center 默认视图
5. 最大化 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 (%) | 在特定方法在堆栈顶部运行时采用的抽样百分比。此值是一个方法对处理资源的使用量的一个不错指标。 |
以下文章点击率最高
Loading…