大厂性能测试监控指标及分析调优指南

一、哪些因素会成为系统的瓶颈

• CPU：如果存在大量的计算，他们会长时间不间断的占用CPU资源，导致其他资源无法争夺到CPU而响应缓慢，从而带来系统性能问题，例如频繁的FullGC，以及多线程造成的上下文频繁的切换，都会导致CPU繁忙，一般情况下CPU使用率<75%比较合适。
• 内存：Java内存一般是通过jvm内存进行分配的，主要是用jvm中堆内存来存储Java创建的对象。内存的读写速度非常快，但是内存空间又是有限的，当内存空间被占满，对象无法回收时，就会导致内存溢出或内存泄漏。
• 磁盘I/O：磁盘的存储空间要比内存存储空间大很多，但是磁盘的读写速度比内存慢，虽然现在引入SSD固态硬盘，但是还是无法跟内存速度相比。
• 网络：带宽的大小，会对传输数据有很大影响，当并发量增加时，网络很容易就会成为瓶颈。
• 异常：Java程序，抛出异常，要对异常进行捕获，这个过程要消耗性能，如果在高并发的情况下，持续进行异常处理，系统的性能会受影响。
• 数据库：数据库的操作一般涉及磁盘I/O的读写，大量的数据库读写操作，会导致磁盘I/O性能瓶颈，进而导致数据库操作延迟。

当在并发编程的时候，经常会用多线程操作同一个资源，这个时候为了保证数据的原子性，就要使用到锁，锁的使用会带来上下文切换，从而带来性能开销，在JDK1.6之后新增了偏向锁、自旋锁、轻量级锁、锁粗化、锁消除。

二、哪些指标做为衡量系统的性能

1.RT响应时间

• 数据库响应时间，即数据库操作的时间
• 服务端响应时间，服务端包括Nginx分发的请求所消耗的时间及服务端程序执行所消耗的时间。
• 网络响应时间，网络传输，网络硬件需要对传输的请求进行解析所消耗的时间
• 客户端响应时间，一般Web、App客户端，消耗时间可以忽略不计，但是如果客户端存在大量的逻辑处理，消耗的时间有能能就会变长。

2.TPS吞吐量

• 磁盘吞吐量：IOPS（Input/Output Per Second）每秒的输入输出量，这种是单位时间内系统能处理的I/O请求数量，I/O请求通常为读或写数据操作请求，关注随机读写性能，适用于随机读写频繁的应用，如小文件存储，邮件服务器。数据吞吐量，这种是单位时间可以传输的数据量，对于大量顺序读写频繁的应用，传输大量连续数据，例如视频编辑。
• 网络吞吐量：指网络传输时没有丢帧的情况下，设备能够接受的最大数据速率。网络吞吐量不仅跟带宽有关系，还跟CPU处理能力、网卡、防火墙、以及I/O等紧密联系，吞吐量的大小由网卡的处理能力、内部程序算法以及带宽大小决定。

3.资源使用率

• CPU使用率，首先可以先了解CPU的基本信息，包括物理CPU的个数、单个CPU的核数，然后可以通过命令查看使用率，vmstat、mpstat、top
• 内存使用率，free -m、vmstat、top
• 磁盘I/O， iostat、 iotop
• 网络I/O，netstat、ifconfig、tcpstat

三、性能测试注意的问题

我们在做性能测试的时候，系统的运行会越来越快，后面的访问速度比我们第一次访问的速度快了好几倍，这是因为Java语言编译的顺序是，.java文件先编译为.class文件，然后通过解释器将.class的字节码转换成本地机器码后，才能运行。

为了节约内存和执行效率，代码最初被执行时，解释器会率先解释执行这段代码。随着代码被执行的次数增多，虚拟机发现某个方法或代码运行的特别频繁，就被认定为热点代码（Hot Spot Code）。

为了提高热点代码的执行效率，在运行时虚拟机将会通过即时编译器（JIT）把这些代码编译成为本地平台相关的机器码，然后储存在内存中，之后每次运行代码时，直接从内存中获取。这样就会导致第一次系统运行慢，后面访问的速度快几倍。

在做性能测试的时候，每次测试处理的数据集都是一样的，但是结果却有差异，这是因为测试时，伴随着很多不稳定因素，比如机器其他进程的影响、网络波动以及每个阶段JVM垃圾回收的不同等。我们可以通过多次测试，将测试结果求平均，只要保证平均值在合理范围之内，并且波动不是很大，这种情况，性能测试就算通过。

四、定位性能问题的时候，可以使用自下而上的策略分析排查

当我们进行压测之后，我们会输出一份性能测试报告，其中包括，RT、TPS、TP99，被压服务器的CPU、内存、I/O，以及JVM的GC频率。通过这些指标可以发现性能瓶颈，我们可以采用自下而上的方式进行分析。

1. 首先从操作系统层面，查看系统的CPU、内存、I/O、网络的使用率是否异常，再通过命令查找异常日志，最后通过日志分析，找到导致瓶颈的问原因。

2. 还可以从Java应用的JVM层面，查看JVM的垃圾回收频率以及内存分配情况是否存在异常，分析垃圾回收日志，找到导致瓶颈的原因。

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

五、优化性能问题的时候，可以使用自上而下的策略进行优化

整体的调优顺序，我们可以从业务调优到编程调优，最后再到系统调优。

1.应用层调优

首先是优化代码，代码问题往往会因为消耗系统资源而暴漏出来，例如代码导致内存溢出，使JVM内存用完，而发生频繁的FullGC，导致CPU偏高。

其次是优化设计，主要是优化业务层和中间件层代码，例如可以采用代理模式，放在频繁调用的创建对象的场景里，共享一个创建对象，减少创建对象的消耗。

再次是优化算法，选择合适的算法降低时间复杂度。

2.中间件调优：MySQL调优

1）表结构与索引优化

主要是对数据库设计、表结构设计以及索引设置维度进行的优化，设计表结构的时候，考虑数据库的水平与垂直的拓展能力，提前规划好将来数据量、读写量的增长，规划好分库分表方案。对字段选择合适的数据类型，优先选用较小的数据结构。

2）SQL语句优化

主要是对SQL语句进行的优化，使用explain来查看执行计划，来查看是否使用了索引，使用了哪些索引。也可以使用Profile命令分析语句执行过程中各个分步的耗时。

3）MySQL参数优化

主要是对MySQL服务的配置进行优化，例如连接数的管理，对索引缓存、查询缓存、排序缓存等各种缓存大小进行优化

4）硬件及系统配置

对硬件设备和操作系统设置进行优化，例如调整操作系统参数、禁用swap、增加内存、升级固态硬盘。

3.系统调优

首先是操作系统调优，Linux操作的内核参数设置可以进行调优，已达到提供高性能的目的。

其次，JVM调优，设置合理的JVM内存空间，以及垃圾回收算法来提高性能，例如，如果业务逻辑会创建大对象，我们就可以设置，将大的对象直接放到老年代中，这样可以减少年轻代频发发生YongGC，减少CPU的占用时间。

4.调优的策略

首先是时间换取空间，有的时候系统对查询速度要求不高，对存储空间要求较高，这个时候我们可以考虑用时间换取空间。

其次是空间换取时间，用存储空间提升访问速度，典型的就是MySQL的分库分表策略，MySQL表单数据存储千万以上的时候，读写性能就会下降，这个时候我们可以将数据进行拆分，以达到查询的时候，每个表的数据是少量的，以达到提升性能的目的。

5.兜底策略

系统调优后，仍然还会存在性能问题，这个时候我们需要有兜底策略， 首先是限流，对系统的入口设置最大访问限制，同时采取断熔措施，返回没有成功的请求。其次是横向扩容，当访问量超过某一个阈值时，系统可以自动横向增加服务。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！