性能测试

基准测试 -> 性能测试 -> 压力测试，我看网上很多文章都在抠这几者的区别，我觉得没什么必要，在本文中不做严格区分。

为什么要做性能测试

• 寻找系统瓶颈

• 对系统性能心中有数

• 为设置接口的限流/熔断做参考

一般两个时间点是必须要做的，大型活动前、新系统上线。压测都是为了系统在线上的处理能力和稳定性维持在一个标准范围内，做到心中有数。

性能测试的局限性

• 基本都是针对单一接口压测。

• 很难与线上保持一样的环境。

• 涉及到缓存、盲区时，不一定能得到想要的真实结果。

所以，性能测试只能作为系统能力的一个佐证指标与参考值。

怎么做性能测试

注意：从整个行业来看，抛开一些大厂不说，全自动化的性能压测环境还是比较少的，要想建设好一套全自动化的性能压测环境起码涉及到几个问题，CI\CD、独立、隔离的压测环境，自动化压测工具、日常压测性能报警、性能报表分析、排查/解决性能问题流程等等。这样才能将性能压测常规化，一旦不是常规化性能压测，就会有代码、中间件配置滞后于生产环境的问题。时间一长，就等于要重新开始搭建、排查压测环境。

压测环境

1. 机器问题（实体机还是虚拟机、CPU、内存、网络适配器进出口带宽、硬盘大小，硬盘是否 SSD、内核基本参数配置）

2. 网络问题（是否有跨网段问题、网段是否隔离、如果有跨网段机器，是否能访问、跨网段是否有带宽限速）

3. 中间件问题（程序里所有依赖的中间件是否有部署、是否与线上架构一致）

这里的难点就是中间件了，该怎么部署、怎么模拟线上场景、模拟什么样的规模、中间件的特性，很多时候压不上去，可以找找中间件的原因。

压测工具

通常使用 Jmeter ，loadRunner、ab 等进行压力测试。

这里的 ab 其实是用来做基准测试的，其实平时我们用来压简单的服务也够用了。

需要知道压力机是否和被压测机器服务器在一个网段，且网段之间没有任何带宽限制。

压测准备

确定并发数

这个需要自己去摸索，比如设置一个预期线上并发数，然后进行测试，进行上下调整。

确定总请求数

有时候单纯的通过并发数并不能完全发现系统的压力状况，因为并发数只能测出系统的处理能力。

但是有时随着长时间的调用，系统可能会出现其他问题。比如：随着数据量的增多，存储磁盘满了、内存缓存用光，缓存服务使用磁盘缓存而拖慢系统等情况。

为了避免这种情况，可以尝试用现在线上业务的请求量来进行模拟（有条件的最好直接使用的流量重放进行压测）。

测试数据选取

通常随机选择数据。但是要注意重复进行压力测试对性能的影响。尤其是有本地缓存时。

压测细节

可以先准备一个 hello word 接口，做网络测试。

如果我们依赖中间件 cache ，那么是否有本地一级 cache ，如果有的话也许对压测环境的中间件 cache 依赖不是太大。如果我们依赖中间件 mq ，是不是在业务上可以断开对 mq 的依赖，因为我们毕竟不是对 mq 进行压测。还有我们所依赖服务也不关心我们的压测波动。

日志记录非常重要！！！

合理的系统架构应该是上层依赖下层，在没有确定下游系统性能的情况下，是没办法确定上游系统性能的瓶颈在哪里。所以压测的顺序应该尽可能的从下往上依次进行，这样可以避免无意义的排查由于下游吞吐量不够带来的性能问题。越是下游系统性能要求越高，因为上游系统的性能瓶颈直接依赖下游系统。

记住一些常用的 linux 命令：netstat、vmstat、mpstat、iostat、top、free 等。

结果分析

压力测试结果

一般要有并发数、总请求数、平均响应时间、中位响应时间、90%响应时间、99%响应时间、最小值、最大值、错误百分比、每分钟吞吐这些指标。

分析方法

当系统出现性能问题的时候可以从两个层面来排查问题，从上往下、从下网上，也可以综合运用这两种方法，压测的时候可以同时查看这两个纬度的信息。

一边打开 top 、free 观察 cpu 、memory 的系统级别的消耗情况，同时一边在通过 jstack 、jstat 之类的工具查看应用程序运行时的内部状态来综合定位。

响应时间不符合要求

通过 pinpoint 、日志 观察调用链，找出耗时比较长的步骤，进行优化

并发数低

1. 检查下各种 pool，web 容器的 worker 线程池、数据库连接池、Redis 连接池等等。

2. 业务流程/代码是否有阻塞瓶颈

3. 查看 GC 频率

CPU 使用率高

1. 查看 GC 频率

2. 查看线程状态

3. 是否有频繁的计算或不合理的循环

总结

随着系统并发的增大，TPS 与占用资源都会正向增加，直到到达某个点（C），随着某些系统资源达到某个瓶颈，会发生资源竞争与阻塞，导致响应时间增加，TPS 反而会下降，并且错误率会上升，如下 2 图：

1. 性能测试时，结果需要进行多次才有意义。

2. 尽量模拟真实业务场景与用例的多样性。

3. 尽量与线上硬件环境一致。

4. 有时候性能压不上去，可能是压测机瓶颈。

5. 压力结果分析工具本身不能代替分析者进行性能结果分析，而只是提供多种不同的数据揭示和呈现方法而已。对于这些数据进行分析必然要依靠程序员对系统性能分析的知识和经验。