除了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的优先级更高。

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

参考：http://www.javashuo.com/article/p-tfxrkylx-ed.html