1 什么是性能指标？

性能指标：任务或系统运行过程中，应用某些评估技术和指标，以评估其运行情况或表现的性能有多好的一种衡量方式。

这里我总结了七个影响最大的指标来衡量系统的性能。

2 七大性能指标

2.1 平均负载

对于 平均负载 指标，通常我们用三阶段法来监测：第5分钟、第15分钟、最后一分钟。

当然这个三阶段监测法有一个前提，那就是应用数量必须低于机器的内核数量。很好理解，当你应用数都超过了机器的内核数了，整个服务器处于高压状态运行，自然这个监测方法也没有什么意义了。

通常我们监测服务器，比如从服务器的 CPU 使用情况、内核队列的线程情况。举个简单的例子，如果 CPU 使用率达到了百分百，内核队列只有1个线程任务和又10个线程任务是不同的。因此平均负载不能只考虑服务器 CPU 的使用率。

对于 平均负载监测工具，这里推荐使用：htop。

2.2 业务指标

其实很多公司对于应用程序的性能大多归于 应用的响应时间 以及 应用的错误率。其实这样是不正确的，虽然应用的响应时间和错误率也是衡量应用性能的一些标准，实际业务指标也是衡量应用性能的指标之一，比如：应用带来的收益、用户量、交易量等。

对于 业务指标监测工具，这里推荐使用：Grafana、The ELK stack、Datadog、Librato。

2.3 GC率和暂停时间

作为JAVA开发者的都知道，JVM有它自己的一些垃圾回收机制，其实垃圾回收器本身的吞吐量和响应时间也会给我们的业务程序的性能带来重要的影响。

因此了解并熟悉JVM的GC的机制原理，通常通过GC的日志文件来分析GC暂停的频率和持续时间，当然还需要JVM参数来作为参考。

同时合理的选用GC回收器以及GC参数配置，也会极大应用的优化性能。

对于 GC率和暂停时间监测工具 ，这里推荐使用：jClarity Censum、GCViewer。

2.4 错误率

对于错误率，我们可以从两个方面来判断：

1、根据HTTP传输总失败的百分比来判断错误率。

2、根据HTPPT特定传输的错误率。

因此在实际生产中，绝大多数开发者仅仅根据HTPP传输总失败的百分比来判断错误率是不对的，他们往往会忽略特定传输的错误率，其实对特定传输的错误率监测可以更好的看出你的应用程序运行状况，可以显示出代码方法的具体错误或者异常的次数。

实际在生产中单纯的错误率对我们是没有什么风用处的，顶多说可以拿着数据来分析应用的错误概率。实际上更重要的是从根源上去解决这些错误。

对于 错误率监测工具 ，这里推荐使用：Takipi。

可以在 Takipi 的日志文件中找到线索。比如服务器的运行状态【包括堆栈跟踪、源代码和变量值查看】

2.5 响应时间和吞吐量

通常应用程序的接口响应时间就可以大概知道程序完成处理需要的时间，这样就可以对特定的接口业务代码进行优化或者对数据库SQL慢查询优化【一方面走程序层面优化，另一方面可走数据库层面优化】来缩短响应时间。

吞吐量是另一个角度衡量传输数据的指标，是指单位时间内系统处理的客户请求的数量。

因此对于响应时间和吞吐量 指标 我们可以用APMs来衡量，可以在著报告仪表盘中把平均响应时长和历史响应时长进行对比，然后来作为分析的依据。

对于 响应时间和吞吐量监测工具 ，这里推荐使用：AppDynamics、New Relic、Ruxit。

可以帮助我们观察新的部署对应用程序有没有什么影响。还可以监测到网络传输的百分比，测量HTTP完成请求需要多长时间。

New Relic 工具的报告，可以监测Web传输百分比和吞吐量。

2.6 日志大小

应该都知道，linux服务发布的应用，它的日志大小会随着时间越长增加的越来越大，如果你的服务器堆满了日志文件，磁盘占用过大，那么服务器运行的性能肯定大打折扣，什么都慢下来了。

对于JAVA程序启动时我们可以设置日志按天打印并打压缩包，对于过于时间长久的日志可以定时迁移到专门的文件存储中去，或者线下管理。

目前通常的解决办法是使用logstash划分使用日志，并将它们发送并存储在Splunk、ELK等日志管理工具中。

对于 日志大小监测工具 ，这里推荐使用：Splunk、Sumo Logic、Loggly。

2.7 服务运行状态和正常运行时间

服务运行状态和正常运行时间指标，直接就能奠定我们的应用程序性能的基础，不仅可以当做一个提醒指标，也可以让你定义一段时间内的SKA。

通常可以用Pingdom的Servlet功能进行运行状态监测。七种应用的所有传输【如数据库和S3】都可以查看到。

对于 服务运行状态和正常运行时间工具 ，这里推荐使用：Pingdom。