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

Posted 2020-12-07 amyzhu

背景

最近发现交给外包做的性能测试，外包人员除了看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