Java 应用发布后，需要关注的7个性能指标（java面试题）

Java 应用发布后，需要关注的7个性能指标（java面试题）

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

数字至上

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

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

1. 响应时间与吞吐量

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

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

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

可行工具：

2. 平均负载

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

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

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

可行工具:

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

3. 错误率（及如何处理）

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

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

4. GC率和中止时间

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

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

可行工具:

5. 业务指标

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

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

可行工具:

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

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

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

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

可行工具:

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

7.日志规模

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

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

最后的思考

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