【性能测试】性能测试指标及Jmeter性能测试（上）

性能测试指标：

1、外部指标，主要关注如下三个指标：

吞吐量：每秒钟系统能够处理的请求数、任务数。

响应时间：服务处理一个请求或一个任务的耗时。

错误率：一批请求中结果出错的请求所占比例。

吞吐量

吞吐量的指标受到响应时间、服务器软硬件配置、网络状态等多方面因素影响。

①吞吐量越大，响应时间越长。

②服务器硬件配置越高，吞吐量越大。

③网络越差，吞吐量越小。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

        QPS（TPS）：每秒钟request/事务 数量

        并发数： 系统同时处理的request/事务数

        响应时间：  一般取平均响应时间

QPS（TPS）= 并发数/平均响应时间

每个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

响应时间

响应时间的指标取决于具体的服务。对实时性要求比较高的服务，响应时间的上限一般在100ms以内。对于响应时间的统计，应从均值、.90、.99、分布等多个角度统计，而不仅仅是给出均值。

如图：

响应时间图

错误率

错误率和服务的具体实现有关。通常情况下，由于网络超时等外部原因造成的错误比例不应超过5%，由于服务本身导致的错误率不应超过1% 。

2、内部指标

从服务器的角度看，性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等。

CPU

Linux系统的CPU主要有如下几个维度的统计数据

us：用户态使用的cpu时间百分比

sy：系统态使用的cpu时间百分比

ni：用做nice加权的进程分配的用户态cpu时间百分比

id：空闲的cpu时间百分比

wa：cpu等待IO完成时间百分比

hi：硬中断消耗时间百分比

si：软中断消耗时间百分比

下图是线上开放平台转发服务某台服务器上top命令的输出，下面以这个服务为例对CPU各项指标进行说明

cpu各项指标

us & sy：大部分后台服务使用的CPU时间片中us和sy的占用比例是最高的。同时这两个指标又是互相影响的，us的比例高了，sy的比例就低，反之亦然。通常sy比例过高意味着被测服务在用户态和系统态之间切换比较频繁，此时系统整体性能会有一定下降。另外，在使用多核CPU的服务器上，CPU 0负责CPU各核间的调度，CPU 0上的使用率过高会导致其他CPU核心之间的调度效率变低。因此测试过程中CPU 0需要重点关注。

ni：每个Linux进程都有个优先级，优先级高的进程有优先执行的权利，这个叫做pri。进程除了优先级外，还有个优先级的修正值。这个修正值就叫做进程的nice值。一般来说，被测服务和服务器整体的ni值不会很高。如果测试过程中ni的值比较高，需要从服务器Linux系统配置、被测服务运行参数查找原因

id：线上服务运行过程中，需要保留一定的id冗余来应对突发的流量激增。在性能测试过程中，如果id一直很低，吞吐量上不去，需要检查被测服务线程/进程配置、服务器系统配置等。

wa：磁盘、网络等IO操作会导致CPU的wa指标提高。通常情况下，网络IO占用的wa资源不会很高，而频繁的磁盘读写会导致wa激增。如果被测服务不是IO密集型的服务，那需要检查被测服务的日志量、数据载入频率等。

hi & si：硬中断是外设对CPU的中断，即外围硬件发给CPU或者内存的异步信号就是硬中断信号；软中断由软件本身发给操作系统内核的中断信号。通常是由硬中断处理程序或进程调度程序对操作系统内核的中断，也就是我们常说的系统调用(System Call)。在性能测试过程中，hi会有一定的CPU占用率，但不会太高。对于IO密集型的服务，si的CPU占用率会高一些。

内存

性能测试过程中对内存监控的主要目的是检查被测服务所占用内存的波动情况。

在Linux系统中有多个命令可以获取指定进程的内存使用情况，最常用的是top命令，如下图所示

其中

VIRT：进程所使用的虚拟内存的总数。它包括所有的代码，数据和共享库，加上已换出的页面，所有已申请的总内存空间

RES：进程正在使用的没有交换的物理内存（栈、堆），申请内存后该内存段已被重新赋值

SHR：进程使用共享内存的总数。该数值只是反映可能与其它进程共享的内存，不代表这段内存当前正被其他进程使用

SWAP：进程使用的虚拟内存中被换出的大小，交换的是已经申请，但没有使用的空间，包括（栈、堆、共享内存）

DATA：进程除可执行代码以外的物理内存总量，即进程栈、堆申请的总空间

从上面的解释可以看出，测试过程中主要监控RES和VIRT，对于使用了共享内存的多进程架构服务，还需要监沙发控SHR。

LOAD（服务器负载）

Linux的系统负载指运行队列的平均长度，也就是等待CPU的平均进程数

从服务器负载的定义可以看出，服务器运行最理想的状态是所有CPU核心的运行队列都为1，即所有活动进程都在运行，没有等待。这种状态下服务器运行在负载阈值下。

通常情况下，按照经验值，服务器的负载应位于阈值的70%~80%，这样既能利用服务器大部分性能，又留有一定的性能冗余应对流量增长。

Linux提供了很多查看系统负载的命令，最常用的是top和uptime

top和uptime针对负载的输出内容相同，都是系统最近1分钟、5分钟、15分钟的负载均值

查看系统负载阈值的命令如下

在性能测试过程中，系统负载是评价整个系统运行状况最重要的指标之一。通常情况下，压力测试时系统负载应接近但不能超过阈值，并发测试时的系统负载最高不能超过阈值的80%，稳定性测试时，系统负载应在阈值的50%左右。

网络

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

网络流量监控

可以使用nethogs命令。该命令与top类似，是一个实时交互的命令，运行界面如下

网络

磁盘IO

性能测试过程中，如果被测服务对磁盘读写过于频繁，会导致大量请求处于IO等待的状态，系统负载升高，响应时间变长，吞吐量下降。

Linux下可以用iostat命令来监控磁盘状态，如下图

tps：该设备每秒的传输次数。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。“一次传输”请求的大小是未知的

ps：该设备每秒的传输次数。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。“一次传输”请求的大小是未知的

kB_read/s：每秒从设备（driveexpressed）读取的数据量，单位为Kilobytes

kB_wrtn/s：每秒向设备（driveexpressed）写入的数据量，单位为Kilobytes

kB_read：读取的总数据量，单位为Kilobytes

kB_wrtn：写入的总数量数据量，单位为Kilobytes

从iostat的输出中，能够获得系统运行最基本的统计数据。但对于性能测试来说，这些数据不能提供更多的信息。需要加上-x参数

rrqm/s：每秒这个设备相关的读取请求有多少被Merge了（当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）

wrqm/s：每秒这个设备相关的写入请求有多少被Merge了

await：每一个IO请求的处理的平均时间（单位是毫秒）

%util：在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，该参数暗示了设备的繁忙程度。

3.常见性能瓶颈

吞吐量到上限时系统负载未到阈值：一般是被测服务分配的系统资源过少导致的。测试过程中如果发现此类情况，可以从ulimit、系统开启的线程数、分配的内存等维度定位问题原因

CPU的us和sy不高，但wa很高：如果被测服务是磁盘IO密集型型服务，wa高属于正常现象。但如果不是此类服务，最可能导致wa高的原因有两个，一是服务对磁盘读写的业务逻辑有问题，读写频率过高，写入数据量过大，如不合理的数据载入策略、log过多等，都有可能导致这种问题。二是服务器内存不足，服务在swap分区不停的换入换出。

同一请求的响应时间忽大忽小：在正常吞吐量下发生此问题，可能的原因有两方面，一是服务对资源的加锁逻辑有问题，导致处理某些请求过程中花了大量的时间等待资源解锁；二是Linux本身分配给服务的资源有限，某些请求需要等待其他请求释放资源后才能继续执行。

内存持续上涨：在吞吐量固定的前提下，如果内存持续上涨，那么很有可能是被测服务存在明显的内存泄漏，需要使用valgrind等内存检查工具进行定位。

测试前准备：

测试数据：由于智能提示已经在线上运行，本次测试使用智能提示趴窝那天的日志作为测试数据

QPS预估：本次测试就是为了找这个数

服务器配置：使用与线上软硬件配置相同的服务器

整理自：https://blog.csdn.net/zhouping19851013/article/details/82898359