性能优化三步骤(一)——性能分析

   从公众号转载，关注微信公众号掌握更多技术动态

---------------------------------------------------------------

一、性能分析简介

    在完成性能测试之后，需要输出一份性能测试报告，分析系统性能测试的情况。其中测试结果需要包含测试接口的平均、最大和最小吞吐量，响应时间，服务器的 CPU、内存、I/O、网络 IO 使用率，JVM 的 GC 频率等。

    通过观察这些调优标准，可以发现性能瓶颈，我们再通过自下而上的方式分析查找问题。首先从操作系统层面，查看系统的 CPU、内存、I/O、网络的使用率是否存在异常，再通过命令查找异常日志，最后通过分析日志，找到导致瓶颈的原因；还可以从 Java 应用的 JVM 层面，查看 JVM 的垃圾回收频率以及内存分配情况是否存在异常，分析日志，找到导致瓶颈的原因。

    如果系统和 JVM 层面都没有出现异常情况，我们可以查看应用服务业务层是否存在性能瓶颈，例如 Java 编程的问题、读写数据瓶颈等等。

1.性能指标

    经常需要对某个性能指标做预测。这种情况就需要研究数据的趋势（Trend）。根据情况做些预测分析，比如根据这个指标的历史数据来进行曲线拟合,经常使用的方法是进行线性回归分析.线性回归是通过拟合自变量与因变量之间最佳线性关系，来预测目标变量的方法。线性回归往往可以预测未来的数据点。比如根据过去几年的每月消费支出数据，来预测明年的每月支出是多少。

对一个系统而言，如果吞吐率很低，响应时间往往会非常稳定。当吞吐率增高时，响应时间一般会快速增加。

(1)响应时间

性能 = 1/ 响应时间

响应时间指的就是执行一个程序，到底需要花多少时间。响应时间是衡量系统性能的重要指标之一，响应时间越短，性能越好，一般一个接口的响应时间是在毫秒级。在系统中，可以把响应时间自下而上细分为以下几种：

• 数据库响应时间：数据库操作所消耗的时间，往往是整个请求链中最耗时的；

• 服务端响应时间：服务端包括 Nginx 分发的请求所消耗的时间以及服务端程序执行所消耗的时间；

• 网络响应时间：这是网络传输时，网络硬件需要对传输的请求进行解析等操作所消耗的时间；

• 客户端响应时间：对于普通的 Web、App 客户端来说，消耗时间是可以忽略不计的，但如果你的客户端嵌入了大量的逻辑处理，消耗的时间就有可能变长，从而成为系统的瓶颈。

(2)吞吐量

    吞吐率是指在一定的时间范围内，到底能处理多少事情。这里的“事情”，在计算机 里就是处理的数据或者执行的程序指令。 和搬东西来做对比，如果响应时间短，可以来回多跑几趟多搬几趟。所 以说，缩短程序的响应时间，一般来说都会提升吞吐率。还可以多找几个人一起来 搬，这就类似现代的服务器都是 8 核、16 核的。人多力量大，同时处理数据，在单位时间 内就可以处理更多数据，吞吐率自然也就上去了

    吞吐率现实中的系统往往有一个峰值极限。超过这个峰值极限，系统就会超载，除了服务延迟超标，还会造成一系列的性能问题（比如系统挂掉）。这个峰值极限往往需要经过仔细的性能测试，并且结合访问延迟标准来确定。有了这个峰值极限值后，系统的设计和运维就需要确保系统的负载不要超过这个值。

    在测试中往往会比较注重系统接口的 TPS（每秒事务处理量），因为 TPS 体现了接口的性能，TPS 越大，性能越好。在系统中，也可以把吞吐量自下而上地分为两种：磁盘吞吐量和网络吞吐量。

①磁盘吞吐量

磁盘性能有两个关键衡量指标

• IOPS（Input/Output Per Second），即每秒的输入输出量（或读写次数），这种是指单位时间内系统能处理的 I/O 请求数量，I/O 请求通常为读或写数据操作请求，关注的是随机读写性能。适应于随机读写频繁的应用，如小文件存储（图片）、OLTP 数据库、邮件服务器。

• 数据吞吐量，这种是指单位时间内可以成功传输的数据量。对于大量顺序读写频繁的应用，传输大量连续数据，例如，电视台的视频编辑、视频点播 VOD（Video On Demand），数据吞吐量则是关键衡量指标。

②网络吞吐量

指网络传输时没有帧丢失的情况下，设备能够接受的最大数据速率。网络吞吐量不仅仅跟带宽有关系，还跟 CPU 的处理能力、网卡、防火墙、外部接口以及 I/O 等紧密关联。而吞吐量的大小主要由网卡的处理能力、内部程序算法以及带宽大小决定。

(3)计算机资源分配使用率

通常由 CPU 占用率、内存使用率、磁盘 I/O、网络 I/O 来表示资源使用率。这几个参数好比一个木桶，如果其中任何一块木板出现短板，任何一项分配不合理，对整个系统性能的影响都是毁灭性的。

资源使用率的标准也需要考虑其他几个重要因素。一个因素是意外事件的缓冲（Buffer）和灾难恢复（Disaster Recovery, or DR）。一个现实世界中的系统，随时都会有意外事件（比如流量波动）或者部分网络故障，这就需要整个系统资源保留一定的缓冲，来应付这些意外和从发生的灾难中恢复。比如 CPU 的使用率，虽然理论上可以到 100%，但考虑这些因素，实际的使用率指标往往远远低于 100%。

• 吞吐量逐步上升，而 CPU 变化很小。这种情况说明系统设计得比较好，能继续“扛”更 高的负载，该阶段可以继续增大请求速率。

• 吞吐量逐步上升，而 CPU 也平稳上升。CPU 使用 随着吞吐量的上升而平稳上升，直到 CPU 成为瓶颈——这里的原因很简单，用于业务处 理的 CPU 是真正“干活的”，这部分的消耗显然是少不了的。如果这种情况下 CPU 已 经很高了却还要优化，那就是说在不能动硬件的情况下，需要改进算法了，因为 CPU 已经在拼命干活了。

• 吞吐量变化很小甚至回落，而 CPU 大幅上升。这种情况说明 CPU 的确在干活，却不是 用于预期内的“业务处理”。最典型的例子就是，内存泄漏

• 吞吐量上不去，CPU 也上不去。这种情况是说，CPU 无法成为瓶颈，因为其它瓶颈先出现了，因此 这种情况下就要检查磁盘 I/O、网络带宽、工作线程数等等。 因此优化的目的，就是努力找到并移除当前的瓶颈，将 CPU 的这个潜力发挥出来。

(4)负载承受能力

当系统压力上升时，你可以观察，系统响应时间的上升曲线是否平缓。这项指标能直观地反馈给你，系统所能承受的负载压力极限。例如，当你对系统进行压测时，系统的响应时间会随着系统并发数的增加而延长，直到系统无法处理这么多请求，抛出大量错误时，就到了极限。

2.性能的度量方式

• 平均值是把这段时间所有请求的响应时间数据相加，再除以总请求数。平均值可 以在一定程度上反应这段时间的性能，但它敏感度比较差，如果这段时间有少量慢请求时， 在平均值上并不能如实的反应。假设在 30s 内有 10000 次请求，每次请求的响应时间都是 1ms，那么这 段时间响应时间平均值也是 1ms。这时，当其中 100 次请求的响应时间变成了 100ms， 那么整体的响应时间是 (100 * 100 + 9900 * 1) / 10000 = 1.99ms。你看，虽然从平均值 上来看仅仅增加了不到 1ms，但是实际情况是有 1% 的请求（100/10000）的响应时间已 经增加了 100 倍。所以，平均值对于度量性能来说只能作为一个参考。

• 最大值就是这段时间内所有请求响应时间最长的值，但它的问题又在于过于敏感 了。 还拿上面的例子来说，如果 10000 次请求中只有一次请求的响应时间达到 100ms，那么这 段时间请求的响应耗时的最大值就是 100ms，性能损耗为原先的百分之一，这种说法明显 是不准确的。

• 分位值有很多种，比如 90 分位、95 分位、75 分位。以 90 分位为例，把这段时间请 求的响应时间从小到大排序，假如一共有 100 个请求，那么排在第 90 位的响应时间就是 90 分位值。分位值排除了偶发极慢请求对于数据的影响，能够很好地反应这段时间的性能 情况，分位值越大，对于慢请求的影响就越敏感。

分位值是最适合作为时间段内，响应时间统计值来使用的，在实际工作中也应用 最多。除此之外，平均值也可以作为一个参考值来使用。

从用户使用体验的角度来看，200ms 是第一个分界点：接口的响应时间在 200ms 之内， 用户是感觉不到延迟的，就像是瞬时发生的一样。而 1s 是另外一个分界点：接口的响应时 间在 1s 之内时，虽然用户可以感受到一些延迟，但却是可以接受的，超过 1s 之后用户就 会有明显等待的感觉，等待时间越长，用户的使用体验就越差。所以，健康系统的 99 分位 值的响应时间通常需要控制在 200ms 之内，而不超过 1s 的请求占比要在 99.99% 以上。