Java 应用发布后，须要关注的7个性能指标

在某个重大发布以后，都须要记录相应的指标，本文介绍了最重要的几个 Java 性能指标，包括响应时间和平均负载等。为理解应用程序在生产环境中如何运行，就须要遵循一些 Java 性能指标。

在之前，当软件被发布后，开发者是没有方法去了解它在生产环境中的运行状况；而如今，几乎任一个你能够想到的指标均可以被监测和报告。时下，开发者面临的问题并非缺少信息，而是信息过载、过大。所以在数百台服务器同时工做的情景下，跟踪记录信息就变得愈来愈困难，虽然多数开发者为了深入理解产品系统仍旧须要利用日志文件，但依然阻挡不了它们逐步被取代的命运。

本文整理了一些重要的指标，使开发者在不借助任何日志文件的状况下，便于理解应用程序在生产环境中运行的具体过程。谈到对 Java 性能的影响，除了像用户负载（或者 AWS 云服务器停机）这样的外部因素，新功能发布多是最多见的诱因。因此在那些新功能发布以后的敏感时段，遵循相应准则变得更为关键。

数字至上

在逐个讨论指标以前，先来强调一个重要问题。有这样一个观点：若是某个观点能够获得数字支持，那么它必定是毋庸置疑的。可是这里存在的问题是，当给你呈现时，不少因素会歪曲你对数据的理解。这么说可能有点抽象，这里能够对比这两个测量用例：首先，在一个简单的时间序列中，观察某一个特定基本指标如何随着时间推移而变化；其次，从不一样的角度观察数据，并保存关注的性能百分比，底线就是必定要关心留意的那个指标所产生的影响，并给以完整性检查以便对其评估。

例如，假设咱们正在观察中值/50百分点处的事务响应时间，由于该点的响应时间已被普遍用做指示符，不少公司将其做为主要KPI之一。在实际中，若单个页面浏览人数达到几十及以上（通常远远超过40），就意味着该用户有99.999...%的可能会经受比中值更差的结果（数学公式可简单的表示为：1 –（0.5 ^ 40） 。所以什么百分点更有意义呢？即便观察点设在第95的百分点，而后你的单页面浏览人数远大于40，那么大部分的用户仍会经受比以前更糟糕的响应时间。若符合多个页面浏览量，事情会更加复杂。想阅读更多关于百分点的知识，了解其对数据的误导，可点击此处进入Gil Tene 的博客。

家下来咱们来仔细解读指标的选择，看看它们各自表明什么，并学习如何来理解这些指标。

1. 响应时间与吞吐量

响应时间用来衡量应用程序中的事务处理速度，它也能够从 HTTP 请求层和数据库层来观察。有些最慢的查询须要最优化解决，而响应时间能够缩小该查询的范围。吞吐量从另外一个角度观察处理过程，并显示应用程序在给定时间域中处理多少请求，一般单位为每分钟（cpm）。

测量响应时间的方法之一就是使用像 New Relic 或者 AppDynamics（就是曾在之前的博客讨论的）那种 APM（应用性能监控工具），经过这些工具，能够追踪平均响应时间，并能够直接在主报告仪表板上与昨日或者上周的平均响应时间做比较，这些比较有助于查看新的部署如何对应用程序形成了影响。另外一种方法是经过测量网页处理的百分位数，来测量 HTTP 请求完成响应所需的时间。

也能够内部监测响应时间，可是须要硬代码，例如经过 Dropwizard 指标发送数据并在 Graphite 上发布。尽管看来将这些数据和其余标准关联时会出现最有用的看法，但更多的看法仍涵盖在接下来的方法中。

要点1: 确保所使用的采集方法能够实现从不一样角度观测数据，并开始进入百分位层面。

可行工具：

1. AppDynamics

2. New Relic

3. Ruxit

4. OneAPM

图为 OneAPM 上监控到的 Java 应用程序响应时间和吞吐量

2. 平均负载

第二个普遍使用的衡量指标就是服务器的平均负载。平均负载习惯上分红3部分，在最后的一、5和15分钟（从左到右）显示其结果。只要分数低于机器内核的数量，就是无压力状态，一旦超过内核数，就意味着机器处于压力状态。

平均负载除了能够简单测量 CPU 利用率，更着重于考量每一个内核目前在队列中有多少进程。某内核利用率达100%，可是却即将结束任务，而另外一内核在队列中还有6个进程要处理，这两种状况是大相径庭的。CPU 这一律念并无涵盖其区别，可是平均负载却能够从大局中考虑此问题。

若在 linux 系统上跟踪平均负载状况，一个极好的方式就是经过 Hisham Muhammad 利用 htop 完成。丰富的色彩加上生动的视觉化效果，瞬间使得命令行有了 NASA 仪表板的即视感。

要点2： 要肯定负载，仅靠资源利用率是不够的，还须要格外注意以便充分了解队列中的进程。

可行工具:

1. htop

图为在一台服务器上运行 htop 以检测负载，平均负载显示在界面的右上角。

3. 错误率（及如处理）

错误率观测有多种方法，而多数开发人员都利用高层次标准——在整个应用层考察错误率，好比在全部 HTTP 请求中考察失败的 HTTP 处理总数。可是还有一个常常被忽视的具体点：特定事务的错误，这与应用程序的运行情况有直接的影响。代码中某一特定方法失败、生成日志错误及发生异常的次数占总调用次数的比重，也要予以显示。

图为 OneAPM 对事务中的错误率监控，随时间监控应用错误率状况。

可是这些数据对其自己并无太大的意义。第一步，从正在处理的事件中优选出最紧急的一件，找到日志错误或异常；第二步，从实际根源处着手，并予以修复。并且基于此问题，已有相应的解决办法。有了 OneAPM ，就没有必要根据日志文件去找错误提示，由于关于服务器状态的全部信息都会在同一界面显示，包括堆栈踪影、实源代码、变量值及每一个错误调用的应用实例。

要点3： 要解决错误率增加的根本缘由，仅靠日志文件是不够的，为了获得大量关于咱们所需指标的数据，还须要利用一些错误率监控工具。

4. GC率和停止时间

垃圾回收器行为异常，是致使应用吞吐量和响应时间忽然降低的主要缘由之一。读者想要了解关于垃圾回收过程的更多知识和相关的标准，可阅读 深刻理解Java虚拟机（第2版）。

分析 GC 日志文件是理解 GC 停止时间和频率的关键。若是不自行分析，或者使用相似于 jClarity 的工具，这种指标是没有办法直接使用的。因此要确保使用合适的 JVM 参数打开 GC 日志采集，以便分析。

要点4： 请记住，分析不一样指标的相关数据，要保持开阔的思惟，这样容易发现它们之间的互相影响。

可行工具:

1. jClarity Censum

2. GCViewer

5. 业务指标

应用的性能不是仅仅依赖于快速响应，也非错误率，另外一个方面就是业务指标。其业务责任也不是只由产品/销售人员全权负责。收入、用户数、与应用中特定区域的互动等，这些都对理解软件的运行极为关键。若要从业务角度观察，你所配置的修复方法和新功能是如何影响底线的，以上因素与新部署的时间标记一块儿做用这一点相当重要。咱们当然但愿状况向好的方向发展，但假如事态恶化，一旦你把全部数据都存在同一位置，要想知道哪里出了问题须要修复，这就至关容易了。

此外，将业务指标与错误率、延时等数据实时链接起来，这种能力是极有力度的。而后会让人情不自禁地深刻研讨究竟是什么错误或异常形成了此次最主要的问题，接着就能够按照对业务目的影响优先考虑它们。想要搞清楚遍及各处的全部异常及日志错误，就得使用集成开放的监测工具。因此，保持数据开放，使其能够输出到选择服务中，这是极其重要的。

假如你要利用 Graphite 将汇报的业务指标集中化，这就要求你所使用的工具对发送数据开放。例如，咱们的工程组就将汇报指标经过 StatsD 发布出来，所以相应数据就能够指向任一用户选择使用的仪表板上。

要点5： 先入先出式数据已经是过去式，在使用指标时，也须要让它们和其余来源的数据相关联。

可行工具:

1. Grafana

2. The ELK stack

3. Datadog

4. Librato

6.正常运行时间和服务运行情况

该指标为总体的工做定下基调。除用做警示媒介外，它还可用于在一段时间内自定义 SLA，以便观察当为用户提供功能完备的服务时所用时间的百分比。

咱们经过运行使用 servlet 的 Pingdom 来解决这个问题，它会对全部应用程序事务中参与的服务进行检查，包括数据库和 S3 等。

要点6： 正常运行时多是二进制指标，可是经过聚合多个值的方式在堆栈中定位薄弱点。

可行工具:

1. Pingdom

图为用 Pingdom 监测正常运行时和应用运行情况。

7.日志规模

以上讨论到的指标除了 GC 都没有提到日志，但这个仍然不可忽略。日志文件的反作用就是它们一直在增加，若是不留意其大小以及抑制，那么后果不堪设想。当日志不受控制，磁盘驱动器极可能被撑爆，服务器中会充斥着垃圾文件，运行缓慢，所以，必定要密切关注日志规模，不然随时会崩溃。

一个普遍使用的解决办法就是，使用 logstash 等将服务器上的日志分块，再将其送入Splunk、ELK 等其余日志管理工具中存储，或者直接简单地存入 S3。另外一种方法就是在某一时间将日志文件翻转再截断，但此法要冒信息丢失的风险。和大部分开发人员同样，目前咱们还必须依赖于日志。

要点7： 日志会给人带来很大的困扰，尤为是当你用某些外部服务来处理日志时，你会被 GB 指控。这时就要从新考虑一下这个问题，还应该开始下降日志大小。

最后的思考

咱们能够看到这一趋势：目前在产品中，应用里的数据采集器正逐渐脱离对日志文件的依赖。软件分析的新世界愈来愈开放，数据更加智能化，已再也不是之前枯燥的数字，而是带有丰富的情境。咱们很兴奋地看着世界的改变，并期待和大家一块儿共建崭新的将来。

原文地址：https://dzone.com/articles/7-java-performance-metrics-to-watch-after-a-major-1