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

标签: java 互联网 发布应用 性能 | 发表时间:2015-12-16 11:49 | 作者:OneAPM蓝海讯通
分享到:
出处:http://segmentfault.com/blogs

在某个重大发布之后,都需要记录相应的指标,本文介绍了最重要的几个 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

Java应用响应时间和吞吐量

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

2. 平均负载

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

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

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

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

可行工具:

  1. htop

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

monitor

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

7.日志规模

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

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

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

最后的思考

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

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

相关 [java 应用 性能] 推荐:

JAVA 应用性能监控基础

- - Linux - 操作系统 - ITeye博客
       这里简单介绍了JAVA 应用程序部署linux 服务器上的一些常用监控信息,虽然现在很多自动化监控的东西,但是一些基本的东西,我们还是需要了解.        1.我习惯性先看看 CPU 和内存的使用情况,做一个简单的关注.           命令:top 可以关注运行状态.           命令:大写P:按CPU 使用排序,大写M:按内存使用排序,小写c:详细显示应用       .

基于 PhoneGap 与 Java 开发的 Android 应用的性能对比

- jinn - 搜索研发部官方博客
        此次的调研的重点是针对一个Android应用的基础需求,用phonegap与Java实现的应用在性能及开发成本等方面的对比.        开发一个应用的最基本需求应该是浏览性需求,而在Android开发中ListView比较常用的控件,广泛被用于数据列表的展现上,而且也比较灵活. 所以本次选择用phonegap和Java各自实现一个ListView的内容展现功能的应用;同时引入另外一个常用组件GridView来实现图片浏览的功能应用.

btrace拓展工具-java应用性能诊断优化利器

- - CSDN博客推荐文章
Btrace是一个实时监控工具,可以无需修改应用代码(事实上它修改了字节码),来达到不可告人的秘密. 它可以获取应用程序代码的执行时间,他可以让你无需修改代码,帮你做时间的打点. 但是,你需要编写btrace脚本,它是一个java文件. 在Eclipse中编写java类很简单,在linux上,vm不熟悉的可能就会比较痛苦了,并且脚本可复制性很强.

打造高性能JAVA应用你需要知道的

- - ImportNew
这篇文章节选自《java performance》,对java性能比较关心的同学大概都知道这本书,性能这个东西可能是很多同学在日常写java code的时候很少去关心的,但是在我们写code的过程中确又时时离不开对程序性能的影响,小到我们使用位运算来实现算术运算,大到我们对JAVA代码的总体架构设计,性能其实离我们很近.

Java 性能调优

- - 编程语言 - ITeye博客
1.用new关键词创建类的实例时,构造函数链中的所有构造函数都会被自动调用. 但如果一个对象实现了Cloneable接口,我们可以调用它的clone()方法. clone()方法不会调用任何类构造函数. 在使用设计模式(Design Pattern)的场合,如果用Factory模式创建对象,则改用clone()方法创建新的对象实例非常简单.

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

- - SegmentFault 最新的文章
在某个重大发布之后,都需要记录相应的指标,本文介绍了最重要的几个 Java 性能指标,包括响应时间和平均负载等. 为理解应用程序在生产环境中如何运行,就需要遵循一些 Java 性能指标. 在以前,当软件被发布后,开发者是没有方法去了解它在生产环境中的运行情况;而现在,几乎任一个你可以想到的指标都可以被监测和报告.

Java应用运维

- - BlueDavy之技术blog
对于互联网产品或长期运行的产品而言,运维工作非常重要,尤其是在产品复杂了以后,在这篇blog中就来说下Java应用的运维工作(ps:虽然看起来各种语言做的系统的运维工作都差不多,但细节上还是会有很多不同,so本文还是只讲Java的). 苦逼的码农按照需求开发好了一个全新的Java Web应用,该发布上线给用户用了,要把一个Java Web应用发布上线,首先需要搭建运行的环境,运行的环境需要有JDK、APPServer,在已经装好了os的机器上装上JDK和APPServer,开发好的Java Web应用可以用maven直接打成war或ear,将这个打好的包scp或其他方式到目标机器上,准备妥当,就差启动了.

[原]Java性能调优

- - 傲慢的上校的专栏
写Java也有n年了,现在还是有不少的坏的代码习惯,也通过学习别人的代码学到了不少好的习惯. 留给自己做个警戒,提示以后写代码的时候注意. 在文章的后面,会提供整理的原材料下载. 1、尽量少用new生成新对象.         用new创建类的实例时,构造雨数链中所有构造函数都会被自动调用,操作速度较慢.

Java性能调优续

- - 编程语言 - ITeye博客
       下面列出一些常见的关于字符串优化的策略,简单的我就不多作解释了. 1) 使用规则表达式处理字符串匹配代替复杂的字符串查找和复制操作;. 2) 使用不拷贝字符串中字符的高效方法,例如String.subString()方法;. 3) 尽可能不要使用需要拷贝字符串中字符的低效方法,例如String.toUpperCase()和String.toLowercase();.

提升Java的锁性能

- - Java译站
几个月前我们介绍了如何通过 Plumbr来 进行线程锁检测,随后便收到了很多类似的问题,“Hi,文章写得不错,现在我终于知道是什么引发的性能问题了,但是现在我该怎么做. 为了在我们的产品中集成这个解决方案,我们付出了许多努力,不过在本文中,我想给大家分享几个常用的优化技巧,而不一定非要使用我们这款锁检测的工具.