企业应用程序中需要捕获的5大Java性能指标

有兴趣了解如何使用AppDynamics捕获这些Java性能指标吗？ 立即开始免费试用 ！

前几篇文章介绍了应用程序性能管理（APM），并指出了有效实施APM战略的挑战。 本文通过回顾五个顶级性能指标来构建这些主题，以评估您的企业Java应用程序的运行状况。

本文专门回顾了以下内容：

• 商业交易
• 外部依赖
• 缓存策略
• 垃圾收集
• 应用拓扑

1.商业交易

商业交易提供了对真实用户行为的洞察力：它们捕获了真实用户在与您的应用程序交互时所经历的实时性能。 如前一篇文章中所述，衡量业务交易的性能涉及整体捕获业务交易的响应时间以及测量其组成层的响应时间。 然后，可以将这些响应时间与最能满足您的业务需求的基线进行比较以确定正常性。

如果您仅要评估应用程序的一个方面，则建议您评估业务交易的行为。 容器度量标准可以提供大量信息，并可以帮助您确定何时自动扩展环境，而业务交易则决定了应用程序的性能。 而不是询问应用程序服务器中的线程池使用情况，您应该询问用户是否能够完成其业务交易，以及这些业务交易是否正常进行。

作为一点背景，业务交易由它们的入口点来标识，这是与启动业务交易的应用程序的交互。 可以通过诸如Web请求，Web服务调用或消息队列中的消息之类的交互来定义业务交易入口点。 或者，您可以选择基于URL参数为同一Web请求定义多个入口点，也可以根据其正文内容为服务调用定义多个入口点。 关键是，业务交易需要与对您的业务有意义的功能相关联。

一旦确定了业务交易，便会在整个应用程序生态系统中衡量其性能。 对照其基准评估每个单独业务交易的绩效以评估正常性。 例如，我们可以确定业务交易的响应时间是否比行为异常的基线的平均响应时间慢两个偏离标准响应时间的标准差。

图1根据基准评估BT响应时间

用于评估业务交易的基准在业务交易运行的小时内是一致的，但是通过每次业务交易执行来完善业务交易。 例如，如果您选择了一个基准，将基准时间与一天中某小时和一周中某天的平均响应时间进行比较，则在当前时间结束后，该小时中执行的所有业务将被合并到基准中下周。 通过这种机制，应用程序可以随着时间的推移而发展，而无需丢弃和重建原始基准。 您可以将其视为随时间推移的窗口。

总而言之，业务交易是对用户体验的最具反映性的度量，因此它们是要捕获的最重要的指标。

2.外部依赖

外部依存关系可以有多种形式：依存的Web服务，遗留系统或数据库； 外部依赖关系是您的应用程序与之交互的系统。 我们不必控制在外部依赖项中运行的代码，但是我们经常可以控制那些外部依赖项的配置，因此了解何时以及何时运行得很好很重要。 此外，我们需要能够区分应用程序中的问题和依赖关系中的问题。

从业务交易的角度来看，我们可以识别和衡量外部依存关系在它们自己的层中。 有时我们需要配置监视解决方案以识别真正包装外部服务调用的方法，但是对于常见协议（例如HTTP和JDBC），可以自动检测到外部依赖关系。 例如，当我在一家保险公司工作时，我们拥有一台AS / 400，并且使用专有协议与之通信。

我们将方法调用确定为外部依赖项，并将其执行归因于AS / 400。 但是我们也有可以为我们自动识别的Web服务调用。 与业务交易及其组成的应用程序层类似，应该将外部依赖行为作为基准，并根据这些基准评估响应时间。

业务事务为您提供了应用程序性能的最佳整体视图，并且可以帮助您分类性能问题，但是外部依赖关系会以意想不到的方式对应用程序产生重大影响，除非您正在观察它们。

3.缓存策略

从内存中服务对象总是比通过网络调用从数据库等系统中检索对象要快。 高速缓存提供了一种在本地存储对象实例的机制，以避免这种网络往返。 但是，如果配置不正确，则缓存可能会带来自身的性能挑战。 常见的缓存问题包括：

• 将太多数据加载到缓存中
• 缓存大小不正确

我与一群不喜欢一般对象关系映射（ORM）工具，特别是不喜欢Level-2缓存的人一起工作。 共识是，ORM工具在决定将哪些数据加载到内存中时过于宽松，并且为了检索单个对象，该工具需要将大量相关数据图加载到内存中。 当正确配置工具时，他们对这些工具的担心几乎没有根据，但是他们发现的问题是真实的。 简而言之，当应用程序仅需要该数据的一小部分时，它们不喜欢将大量相互关联的数据加载到内存中。

在测量高速缓存的性能时，需要确定加载到高速缓存中的对象数，然后跟踪正在使用的那些对象的百分比。 要查看的关键指标是缓存命中率和从缓存中弹出的对象数。 高速缓存命中计数或命中率报告从高速缓存处理的对象请求的数量，而不需要进行网络行程来检索对象。

如果高速缓存很大，则命中率很小（低于10％或20％），并且您看不到从高速缓存中弹出许多对象，那么这表明您正在向高速缓存中加载过多数据。 换句话说，您的缓存足够大，不会抖动（请参阅下文），并且包含许多未使用的数据。

测量缓存性能时要考虑的另一个方面是缓存大小。 如上例所示，缓存是否太大？ 缓存是否太小？ 还是缓存大小合适？

调整缓存大小时的一个常见问题是无法正确预期用户的行为以及缓存的使用方式。 让我们考虑配置为承载100个对象的缓存，但是该应用程序在任何给定时间需要300个对象。 前100个调用会将初始对象集加载到缓存中，但是后续调用将找不到他们要查找的对象。 结果，缓存将需要选择要从缓存中删除的对象，以便为新请求的对象腾出空间，例如使用最近最少使用（LRU）算法。

该请求将需要通过网络执行查询以检索对象，然后将其存储在缓存中。 结果是我们花费更多的时间来管理缓存而不是服务对象：在这种情况下，缓存实际上是在阻碍而不是提高性能。 由于Java的性质以及它如何管理垃圾回收，进一步加剧了问题，这种从缓存中不断添加和删除对象的方法实际上会增加垃圾回收的频率（请参见下文）。

当您将高速缓存的大小设置得太小并且发生上述行为时，我们说高速缓存正在抖动，在这种情况下，没有高速缓存比抖动的高速缓存更好。 图2试图以图形方式显示。

图2缓存释放

在这种情况下，应用程序从缓存中请求一个对象，但是找不到该对象。 然后，它通过网络在外部资源中查询对象，并将其添加到缓存中。 最后，缓存已满，因此需要选择一个要从缓存中弹出的对象，以便为新对象腾出空间，然后将新对象添加到缓存中。

有兴趣了解如何使用AppDynamics捕获这些Java性能指标吗？ 立即开始免费试用 ！

4.垃圾收集

Java提供的核心功能（可追溯到其最初发行版）是垃圾收集，它既是福也是祸。 垃圾回收使我们摆脱了手动管理内存的责任：完成使用对象后，我们只需删除对该对象的引用，垃圾回收将自动为我们释放它。 如果您来自需要手动内存管理的语言（例如C或C ++），您将欣赏到这减轻了分配和释放内存的麻烦。

此外，由于垃圾收集器在没有对该内存的引用时自动释放内存，因此它消除了在分配内存并在释放内存之前删除对该内存的引用时发生的传统内存泄漏。 听起来像万能药，不是吗？

垃圾收集实现了消除手动内存管理并使我们摆脱传统内存泄漏的目标，但这样做的代价是有时会很麻烦。 有几种基于您使用的JVM的垃圾收集策略，并且不涉及本文的讨论范围，但是足以说明您需要了解垃圾收集器的工作方式以及实现垃圾收集的最佳方法。配置它。

垃圾收集的最大敌人被称为大型或完整垃圾收集。 除了Azul JVM之外，所有JVM都遭受主要垃圾回收的困扰。 垃圾收集有两种一般形式：

• 次要
• 重大的

较小的垃圾收集相对频繁地发生，目的是释放短暂的对象。 它们不会在运行时冻结JVM线程，并且通常不会产生重大影响。

另一方面，主要的垃圾收集有时也称为“世界停止”（STW）垃圾收集，因为它们在运行时会冻结JVM中的每个线程。 为了说明这种情况是如何发生的，我在本书《 Pro Java EE 5性能管理和优化》中提供了一些数据。

图3可达性测试

运行垃圾回收时，它将执行称为可达性测试的活动，如图3所示。它构造对象的“根集”，其中包括每个运行线程直接可见的所有对象。 然后，它遍历由根集中的对象引用的每个对象以及这些对象引用的对象，依此类推，直到所有对象都被引用为止。 在执行此操作时，它“标记”活动对象正在使用的内存位置，然后“清除”所有未使用的内存。 更恰当地说，它从根集中释放了没有对象引用路径的所有内存。 最后，它压缩或整理内存碎片，以便可以分配新对象。

次要集合和主要集合取决于您的JVM，但图4和5显示了次要集合和主要集合如何在Sun JVM上运行。

图4次要收藏

在次要收集中，将在Eden空间中分配内存，直到Eden空间已满。 它执行一个“复制”收集器，将活动对象（可达性测试）从伊甸园复制到两个幸存者空间之一（到空间和从空间）。 然后可以将留在伊甸园中的物体扫走。 如果幸存者空间已满，而我们仍然有活动对象，则这些活动对象将被移至保管空间，在那里只有大集合可以释放它们。

图5主要收藏

最终，保有权空间将被填满，并且次要集合将运行，但是保管空间中将没有任何空间可以复制不适合生存空间的活动对象。 发生这种情况时，JVM冻结JVM中的所有线程，执行可达性测试，清除年轻的一代（Eden和两个幸存者空间），并压缩保有权空间。 我们称此为主要收藏。

如您所料，堆越大，大型集合运行的频率就越小，但是当运行时，它们比较小的堆花费的时间长得多。 因此，调整堆大小和垃圾回收策略以满足应用程序行为很重要。

5.应用拓扑

在前5个列表中要衡量的最终性能组件是您的应用程序拓扑。 由于云的出现，应用程序现在本质上可以具有弹性：您的应用程序环境可以增长和缩小以满足用户需求。 因此，对您的应用程序拓扑进行清单清点以确定确定环境的最佳大小非常重要。 如果您有太多的虚拟服务器实例，那么您的云托管成本将会增加，但是如果您没有足够的数量，那么您的业务交易将会受到影响。

在此评估过程中测量两个指标很重要：

• 商业交易量
• 容器性能

应该将业务交易作为基准，并且您应该在任何给定的时间知道满足基准所需的服务器数量。 如果您的业务事务负载意外增加，例如超过正常负载标准偏差的两倍，则您可能需要添加其他服务器以满足这些用户的需求。

另一个要衡量的指标是容器的性能。 具体来说，您要确定是否有任何服务器层处于胁迫状态，如果存在，则可能需要向该层添加其他服务器。 查看整个层中的服务器很重要，因为单个服务器可能由于垃圾收集等因素而处于胁迫状态，但是如果层中很大比例的服务器处于胁迫状态，则可能表明该层无法支持负载它正在接收。

由于您的应用程序组件可以单独扩展，因此分析每个应用程序组件的性能并相应地调整拓扑非常重要。

结论

本文介绍了在评估应用程序的运行状况时可能需要衡量的前五项指标。 总之，前五项是：

• 商业交易
• 外部依赖
• 缓存策略
• 垃圾收集
• 应用拓扑

在下一篇文章中，我们将把本系列的所有主题放在一起，以介绍AppDynamics实施其APM战略所采用的方法。 这不是一篇营销文章，而是对为何做出某些决策和优化以及它们如何为您提供虚拟或基于云应用程序运行状况的强大视图的解释。

有兴趣了解如何使用AppDynamics捕获这些Java性能指标吗？ 立即开始免费试用 ！

翻译自: https://www.javacodegeeks.com/2015/05/top-5-java-performance-metrics-to-capture-in-enterprise-applications.html