性能测试常见指标

最新推荐文章于 2024-10-10 14:26:51 发布

hahavslinb

最新推荐文章于 2024-10-10 14:26:51 发布

阅读量10w+

点赞数 65

分类专栏：性能测试文章标签：性能测试

性能测试专栏收录该内容

5 篇文章 5 订阅

订阅专栏

最近在学习性能测试的东西，对于一些常见性能测试指标做些总结，保存在这里方便后期查阅，文中摘抄自某大神的博客，文末放原文链接，有需要的童鞋可以更深入了解！

什么是性能测试？

压力测试：强调极端暴力
稳定性测试：在一定压力下，长时间运行的情况
基准测试：在特定条件下的性能测试
负载测试：不同负载下的表现
容量测试：最优容量

概述

不同人群关注的性能指标各有侧重。后台服务接口的调用者一般只关心吞吐量、响应时间等外部指标。后台服务的所有者不仅仅关注外部指标，还会关注CPU、内存、负载等内部指标。

拿某打车平台来说，它所关心的是智能提示的外部指标能不能抗住因大波优惠所导致的流量激增。而对于智能提示服务的开发、运维、测试人员，不仅仅关注外部指标，还会关注CPU、内存、IO等内部指标，以及部署方式、服务器软硬件配置等运维相关事项。

外部指标

从外部看，性能测试主要关注如下三个指标

吞吐量：每秒钟系统能够处理的请求数、任务数。
响应时间：服务处理一个请求或一个任务的耗时。
错误率：一批请求中结果出错的请求所占比例。

响应时间的指标取决于具体的服务。如智能提示一类的服务，返回的数据有效周期短（用户多输入一个字母就需要重新请求），对实时性要求比较高，响应时间的上限一般在100ms以内。而导航一类的服务，由于返回结果的使用周期比较长（整个导航过程中），响应时间的上限一般在2-5s。

对于响应时间的统计，应从均值、.90、.99、分布等多个角度统计，而不仅仅是给出均值。下图是响应时间统计的一个例子

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

吞吐量越大，响应时间越长。
服务器硬件配置越高，吞吐量越大。
网络越差，吞吐量越小。

在低吞吐量下的响应时间的均值、分布比较稳定，不会产生太大的波动。

在高吞吐量下，响应时间会随着吞吐量的增长而增长，增长的趋势可能是线性的，也可能接近指数的。当吞吐量接近系统的峰值时，响应时间会出现激增。

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

一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。

单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。

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

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

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

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

（很多人经常会把并发数和TPS理解混淆）

理解了上面三个要素的意义之后，就能推算出它们之间的关系：

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

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

决定系统响应时间要素

我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期。

系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统影响时间；

关键路径是有CPU运算、IO、外部系统响应等等组成。

我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。

而通常境况下，我们面对需求，我们评估出来的出来QPS、并发数之外，还有另外一个维度：日PV。

通过观察系统的访问日志发现，在用户量很大的情况下，各个时间周期内的同一时间段的访问流量几乎一样。比如工作日的每天早上。只要能拿到日流量图和QPS我们就可以推算日流量。

通常的技术方法：

1. 找出系统的最高TPS和日PV，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响之外）

2. 通过压力测试或者经验预估，得出最高TPS，然后跟进1的关系，计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不一样，这两个客户群的网络行为不应用，他们之间的TPS和PV关系比例也不一样。

A)淘宝

淘宝流量图：

系统吞吐量评估方法

淘宝的TPS和PV之间的关系通常为最高TPS：PV大约为 1 : 11*3600 （相当于按最高TPS访问11个小时，这个是商品详情的场景，不同的应用场景会有一些不同）

B) B2B中文站

B2B的TPS和PV之间的关系不同的系统不同的应用场景比例变化比较大，粗略估计在1 : 8个小时左右的关系（09年对offerdetail的流量分析数据）。旺铺和offerdetail这两个比例相差很大，可能是因为爬虫暂的比例较高的原因导致。

在淘宝环境下，假设我们压力测试出的TPS为100，那么这个系统的日吞吐量=100*11*3600=396万

这个是在简单（单一url）的情况下，有些页面，一个页面有多个request，系统的实际吞吐量还要小。

无论有无思考时间（T_think），测试所得的TPS值和并发虚拟用户数(U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关系（稳定运行情况下）：
TPS=U_concurrent / (T_response+T_think)。

并发数、QPS、平均响应时间三者之间关系

系统吞吐量评估方法

来源：http://www.cnblogs.com/jackei/

内部指标

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

CPU

后台服务的所有指令和数据处理都是由CPU负责，服务对CPU的利用率对服务的性能起着决定性的作用。

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

us：用户态使用的cpu时间百分比
sy：系统态使用的cpu时间百分比
ni：用做nice加权的进程分配的用户态cpu时间百分比
id：空闲的cpu时间百分比
wa：cpu等待IO完成时间百分比
hi：硬中断消耗时间百分比
si：软中断消耗时间百分比

下图是线上开放平台转发服务某台服务器上top命令的输出，下面以这个服务为例对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类似，是一个实时交互的命令，运行界面如下

在后台服务性能测试中，对于返回文本结果的服务，并不需要太多关注在流量方面。

网络连接状态监控

性能测试中对网络的监控主要是监控网络连接状态的变化和异常。对于使用TCP协议的服务，需要监控服务已建立连接的变化情况（即ESTABLISHED状态的TCP连接）。对于HTTP协议的服务，需要监控被测服务对应进程的网络缓冲区的状态、TIME_WAIT状态的连接数等。Linux自带的很多命令如netstat、ss都支持如上功能。下图是netstat对指定pid进程的监控结果

磁盘IO

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

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

tps：该设备每秒的传输次数。“一次传输”意思是“一次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%，该参数暗示了设备的繁忙程度。

常见性能瓶颈

吞吐量到上限时系统负载未到阈值：一般是被测服务分配的系统资源过少导致的。测试过程中如果发现此类情况，可以从ulimit、系统开启的线程数、分配的内存等维度定位问题原因
CPU的us和sy不高，但wa很高：如果被测服务是磁盘IO密集型型服务，wa高属于正常现象。但如果不是此类服务，最可能导致wa高的原因有两个，一是服务对磁盘读写的业务逻辑有问题，读写频率过高，写入数据量过大，如不合理的数据载入策略、log过多等，都有可能导致这种问题。二是服务器内存不足，服务在swap分区不停的换入换出。
同一请求的响应时间忽大忽小：在正常吞吐量下发生此问题，可能的原因有两方面，一是服务对资源的加锁逻辑有问题，导致处理某些请求过程中花了大量的时间等待资源解锁；二是Linux本身分配给服务的资源有限，某些请求需要等待其他请求释放资源后才能继续执行。
内存持续上涨：在吞吐量固定的前提下，如果内存持续上涨，那么很有可能是被测服务存在明显的内存泄漏，需要使用valgrind等内存检查工具进行定位。

举个 (栗子) 例子

智能提示服务趴窝了以后，必须立刻对其做性能摸底。根据目前的情况，测试结果中需要提供外部指标和内部指标。

智能提示服务的架构和每个模块的功能如下图所示

从图中我们可以看出，测试前智能提示服务的底层数据服务已经确定了性能上限。因此，本次测试我们的任务是在底层数据服务性能为3500qps的前提下，找到智能提示服务上游各个模块的性能上限。

一个完整的后台服务性能测试流程如下图所示。

测试前准备：

测试数据：由于智能提示已经在线上运行，本次测试使用智能提示趴窝那天的日志作为测试数据
QPS预估：本次测试就是为了找这个数
服务器配置：使用与线上软硬件配置相同的服务器

压测过程：

我们使用Jmeter发送测试数据来模拟用户请求，Jmeter测试配置文件使用的原件如下图所示。从图中可以看出，性能测试的配置文件主要由数据文件配置（线程间共享方式、到达末尾时的行为等）、吞吐量控制、HTTP采样器（域名、端口、HTTP METHOD、请求body等）、响应断言（对返回结果的内容进行校验）。

数据文件配置

吞吐量控制

HTTP请求采样

响应断言

在linux中，sar、top、ps等命令都可以对cpu使用情况进行监控。一般来说，最常用的是top命令。top命令的输出如下：

top命令是一个交互式命令，运行后会一直保持在终端并定时刷新。在性能测试中，可以使用如下参数让top命令只运行一次

$top –n 1 –b –p ${pid}

服务器负载

linux中，服务器负载使用uptime命令获取，该命令的输出如下图

每一列的含义如下：

“当前时间系统运行时长登录的用户数最近1分钟、5分钟、15分钟的平均负载”

内存

在linux中， top、ps命令都可以对指定进程的内存使用状况进行查看。但最准确的信息在/proc/${PID}/status中，如下图

上面命令的输出中，我们重点关注VmRSS、VmData、VmSize

磁盘IO

磁盘监控数据使用iostat命令获取

测试报告输出

在统计完性能测试过程中收集的监控指标后，就可以输出性能报告了。

通常来说，性能报告中要包含如下内容：

测试结论：包括被测服务最大QPS、响应时间等指标是否达到期望，部署建议等。
测试环境描述：包括性能需求、测试用服务器配置、测试数据来源、测试方法等
监控指标统计：响应时间统计、QPS、服务器指标统计、进程指标统计。建议最好用图表来表示统计数据。

结语

测试完毕后，得出的结论是单台智能提示服务的性能是300qps，线上整套智能提示服务的性能是1800qps；而月黑风高那天的流量大概是5000qps+，难怪智能提示趴窝，确实流量太大，远超线上的吞吐容量。

最后，智能提示服务申请了服务器进行扩容，并对某打车平台的流量进行了限制，既开源又节流，保证今后月黑风高之夜一众约酒、约饭、约P之人的打车体验，提高了各种约的成功率，可谓功德无量。

软件性能的关注点

对一个软件做性能测试时需要关注那些性能呢？

我们想想在软件设计、部署、使用、维护中一共有哪些角色的参与，然后再考虑这些角色各自关注的性能点是什么，作为一个软件性能测试工程师，我们又该关注什么？

首先，开发软件的目的是为了让用户使用，我们先站在用户的角度分析一下，用户需要关注哪些性能。

对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间，当相应时间较小时，用户体验是很好的，当然用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索，这时用户并不知道我们后台在做什么。

用户关注的是用户操作的相应时间。

其次，我们站在管理员的角度考虑需要关注的性能点。

1、相应时间
2、服务器资源使用情况是否合理
3、应用服务器和数据库资源使用是否合理
4、系统能否实现扩展
5、系统最多支持多少用户访问、系统最大业务处理量是多少
6、系统性能可能存在的瓶颈在哪里
7、更换那些设备可以提高性能
8、系统能否支持7×24小时的业务访问

再次，站在开发（设计）人员角度去考虑。

1、架构设计是否合理
2、数据库设计是否合理
3、代码是否存在性能方面的问题
4、系统中是否有不合理的内存使用方式
5、系统中是否存在不合理的线程同步方式
6、系统中是否存在不合理的资源竞争

那么站在性能测试工程师的角度，我们要关注什么呢？

一句话，我们要关注以上所有的性能点。

二、软件性能的几个主要术语

1、响应时间：对请求作出响应所需要的时间

网络传输时间：N1+N2+N3+N4

应用服务器处理时间：A1+A3

数据库服务器处理时间：A2