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

Testingba工作室 2020-05-31

背景

最近发现交给外包做的性能测试,外包人员除了看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%,这样既能服务器大部分性能,又留有一定的性能冗余应对流量增长。
  • 查看系统负载的命令:topuptime, 输出系统最近1分钟、5分钟、15分钟的负载均值。
  • 性能测试:并发测试时系统的负载最高不能超过阈值的80%;稳定性测试,系统负载应在阈值的50%左右。

网络相关指标

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

  • 网络流量监控:可以好似哟功能nethogs
  • 网络连接状态监控:主要监控网络连接状态的变化和异常。
    • TCP协议的服务,需要监控服务已建立连接的变化情况(即ESTABLISH状态的TCP连接)。
    • HTTP协议的服务,需要监控被测服务对应进程的网络缓冲区的状态,TIME_WAIT状态的连接数等。
    • 常用命令:netstatss
      • 监控指定进程: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

相关推荐