除了RPS和错误率，性能测试还需要关注这些指标

背景

最近发现交给外包做的性能测试，外包人员除了看RPS、错误率，其他指标完全不看。

我陷入了思考，现在很多公司为了降低性能测试的门槛，内部会针对一些开源框架进行二次开发，以用户非常友好的WEB页面呈现出来。因此，在很多测试人员看来，所谓的性能测试不就是调一下并发，看看页面显示的RPS，哪里报错，就找开发定位。这么简单，哪有什么神秘感？真的是这样吗？如果是这样，为什么性能测试专家这么吃香？为什么有一些人可以在性能测试领域深耕多年甚至超过十年？换一个思路，当你进行性能摸底，发现某个节点，RPS就上不去了，你不好奇为什么吗？为什么不懂得去看看系统指标，确定哪里是瓶颈？

反正我觉得性能测试最有意思的就是测试过程的问题定位、排查，性能测试结束之后的瓶颈分析、结论分析。所以，写了这篇文章，想告诉大家除了RPS和错误率，你还可以关注什么。

施压端

RPS：即吞吐量，每秒钟系统可以处理的请求数、任务数。
请求响应时间
- 服务处理一个请求或者任务的耗时，包括网络链路耗时。
- 分类：平均值、99分位数、中位数、最大值最小值
错误率：一批请求中结果出错的请求所占比例。

被测服务

CPU
内网
IO wait
网络带宽
Load：负载
- TOP：1min、5min、15min

Linux系统的CPU统计维度

us：用户态使用的cpu时间百分比
sy：系统胎使用的cpu时间百分比
- sy过高意味着被测服务在用户态和系统态之间切换比较频繁，此时系统整体性能会有一定下降
- 在使用多核CPU的服务器上，CPU0负责CPU各核之间的调度，CPU0的使用率过高会导致其他CPU核心之间的调度效率变低。
ni：用做nice加权的进程分配的用户态cpu时间百分比
- 一般来说，被测服务和服务器整体的ni值不会很高，如果测试过程中nic的值比较高，需要从服务器Linux系统配置、被测服务运行参数查找原因。
id：空闲的cpu时间百分比
- 线上服务运行过程，需要保留一定的idle冗余来应对突发的流量激增。
- 性能测试过程中，如果id一直很低，吞吐量上不去，需要检查被测服务线程/进程配置、服务器系统配置等。
wa：cpu等待io完成时间百分比
- 磁盘、网络等IO操作会导致CPU的wa指标增高。通常情况下，网络IO占用的wa资源不会很高，而频繁的磁盘读写会导致wa激增。
- 影响IO的因素：日志量、数据载入频率等。
hi：硬中断消耗时间百分比
- 硬中断：外设对CPU的中断
si：软中段消耗时间百分比
- 软中断：软件本身发给操作系统内核的中断信号。
- IO密集型的服务，si的CPU占用率会高一些。

内存统计维度

VIRT：进程所使用的虚拟内存的总数。它包括所有的代码、数据和共享库，加上已经SWAP的页面，所有已申请的总内存空间。
RES：进程正在使用的没有交换的物理内存（堆、栈）
SHR：进程使用共享内存的总数。该数值只是反映可能与其他进程共享的内存，不代表这段内存当前正被其他进程使用。
SWAP：进程使用的虚拟内存中被换出的大小，交换的是已经申请，但没有使用的空间，包括堆、栈、共享内存
DATA：进程可执行代码以外的物理内存总量，即进程栈、堆申请的总空间。

load

load：指运行队列的平均长度，也就是等待CPU的平均进程数。
服务器运行最理想的状态是所有CPU核心的运行队列都为1，即所有活动进程都在运行，没有等待。
按照经验值，服务器的负载应位于阈值的70%～80%，这样既能服务器大部分性能，又留有一定的性能冗余应对流量增长。
查看系统负载的命令：top、uptime, 输出系统最近1分钟、5分钟、15分钟的负载均值。
性能测试：并发测试时系统的负载最高不能超过阈值的80%；稳定性测试，系统负载应在阈值的50%左右。

网络相关指标

性能测试中网络监控主要包括网络流量、网络连接状态的监控。

网络流量监控：可以好似哟功能nethogs
网络连接状态监控：主要监控网络连接状态的变化和异常。
- TCP协议的服务，需要监控服务已建立连接的变化情况（即ESTABLISH状态的TCP连接）。
- HTTP协议的服务，需要监控被测服务对应进程的网络缓冲区的状态，TIME_WAIT状态的连接数等。
- 常用命令：netstat、ss
  - 监控指定进程：netstat -nalp | grep pid

磁盘IO关注数据

常用命令：iostat iostat -x -d 2 6
tps：设备每秒的传输次数。一次传输指一次I/O请求。
kB_read/s：每秒从设备读取的数据量，单位为 kb
kB_wrtn/s：每秒向设备写入的数据量，单位为Kb
kB_read：读取的总数据量，单位为Kb
Kb_wrtn：写入的总数据量，单位为Kb
rrqm/s：每秒这个设备相关的读取请求有多少被Merge了。
- Merge：当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同block的数据，FS会将这个请求合并Merge
wrqm/s：每秒这个设备相关的写入请求有多少被merge了
await：每一个IO请求的处理的平均时间，单位是毫秒
%util：在统计内所有处理IO时间，除以总共统计时间。该参数表示设备的繁忙程度。

常见性能瓶颈

吞吐量到上线时系统负载未到阈值：可能原因
1. 被测服务分配的系统资源过少
CPU的us和sy不高，但wa很高：可能原因
1. 被测服务是IO密集型服务
2. 服务对磁盘读写的业务逻辑有问题，读写频率过高，写入数据量过大
3. 服务器内存不足，服务在swap分区不停的换入换出
同一请求的响应时间忽大忽小，可能原因：
1. 服务对资源的加锁逻辑有问题，导致某些请求过程中花了大量的时间等待资源解锁
2. Linux本身分配给服务器的资源有限，某些请求需要等待其他请求释放自由后才能继续运行
内存持续上涨：可能是被测服务存在内存泄漏，需要使用valgrind等内存检测工具进行定位。

附录：nice值

top命令中ni指：用户进程空间内改变过优先级的进程占用CPU百分比。

nice：指进程可被执行的优先级的修正数值。
nice取值： -20～19，用户可以设置的最大值为19.
可以通过修改进程优先级来加速进程运行
- renice -10 -p pid
PRI：进程的优先级，值越小进程的优先级越高
- PRI（new）=PRI（old）+nice
- PR是根据nice排序的，规则是nice越小优先级变高，进程越快被执行。如果nice相同进程uid是root的优先级更高。

思考时间：指用户进行操作时每个请求之间的时间间隔。

参考：https://blog.csdn.net/hahavslinb/article/details/78673267