20230114_性能测试-性能测试指标
本文总结接口性能测试中,常见的性能指标概念,查看及通用通过标准
注: 本文只考虑B/S架构
Reference
《LoadRunner 没有告诉你的》之三——理发店模型 - Jackei - 博客园 (cnblogs.com)
(91条消息) 详解磁盘IO、网络IO、零拷贝IO、BIO、NIO、AIO、IO多路复用(select、poll、epoll)_雷恩Layne的博客-CSDN博客_网络io和磁盘io的区别 – 磁盘IO, 网络IO概念理解
(91条消息) 【性能测试】性能测试之性能测试指标详解(性能指标、CPU、内存、负载、磁盘)_微橙的博客-CSDN博客_性能测试 服务吞吐量很低 cpu不高 – CPU,内存,磁盘IO性能指标
面试官之问:知道你的接口“QPS”是多少吗? - 知乎 (zhihu.com)
4.性能测试指标.pdf
Jmeter.xlsx
客户端指标
并发用户数Load
什么是并发用户数?
多个用户在同一时期内进行相同的事物或者操作称为并发, 而用户数量称为并发用户数
- 绝对并发: 多个用户同一时刻对服务端进行请求
- 相对并发: 多个用户同一时间段对服务器进行请求
并发用户数和产品性能的关系
谈到并发用户数就要提到著名的理发店模型(见Reference), 我这里做简单摘要
- 场景: 理发店(产品)有多个理发师(服务器), 越来越多的顾客(用户)过来理发
- Light Load: 师傅多客少;理发师还有空抽个烟,刷个手机;顾客来了就剪,剪完就走,体验不错
- Heavy Load: 师傅少客多;理发师虽然忙个不停,但仍然井井有条; 顾客等待的时间越来越长
- Buckle Zone: 师傅少客人贼多; 理发师开始安抚等待的客人维持秩序, 剪发的效率下降; 顾客等待的时间指数级增长, ,而且没板凳坐,不满得喊理发师搬板凳
- 最佳并发数: Light Load和Heavy Load的临界点,超过此节点开始影响客户的体验
- 最大并发数: Heavy Load和Buckle Zone的临界点. 超过此节点理发师开始自乱阵脚

设定及查看方式
- 设定测试计划时, 选择合适的并发用户数对系统进行测试
- 通过性能测试, 通过找到产品的最佳并发数和最大并发数
准过标准
- 最佳并发数应该大于系统平均负载, 否则需要进行优化
响应时间RT
概念
指从客户发送请求到接收到反馈所花费的时间
花费的时间可分为:
- 浏览器: 接受资源时间, 页面渲染时间
- 网络传输: 外部网络传输时间, 服务器内部网络传输时间(一般忽略不计)
- 接入层: 接入层处理时间(一般忽略不计)
- 服务器: 逻辑处理时间, I/O消耗,第三方依赖(rpc服务器,读写mq,读写缓存)
- 数据库: 数据库DML处理时间
查看方式
- Jmeter通过Aggregate Report查看, 主要查看平均时间,95% Line及99% Line
准过标准
- 平均时间: 2/5/8标准
- 95% Line及99% Line 时间不能高于平均时间太多(自己拿捏吧)
不同架构的软件,不同的行业, 不同的使用场景,对于RT的要求都不同, 往往需要参考公司内部测试规范和惯例能确定标准
每秒事物数TPS
概念
每秒系统处理的事务量, 事务维度衡量吞吐量的一个指标
- 计算公式: 处理事务数/处理时间
- 一个事务可以理解为一次页面操作后服务器返回客户所需数据的过程, 一个事务可能需要1个或多个接口
- 服务器每秒查询数QPS指的是服务器每秒可以处理多少流量, 这个指标用来看服务器行不行
而TPS用来看接口和事务行不行
查看方式
- Jmeter通过Aggregate Report查看,Throughput代表的就是TPS; Jmeter中的事务和接口都会有自己的TPS
准过标准
不同行业有不同的要求,没有绝对标准
同一个事务中多个接口RT相差很大时, 需要对较差的接口TPS进行优化
接口全部返回数据后, 页面才能全部展示, 补足短板
失败率Error%
概念
所有请求中失败请求的占比
查看方式
- Jmeter中通过Aggregate Report查看
准过标准
- 一般业务: 失败率<0.5%
- 重要业务: 失败率=0
点击率Hit Rate
概念
性能测试指, 单位时间内点击的次数, jmeter指单位时间内的请求数
查看方式
- jmeter中通过Listener-Hits Per Second查看每秒点击次数
准过标准
无通用标准, 一般用于在点击次数层面衡量对服务器的压力
服务器指标
服务器主要关注CPU,内存, 磁盘和网络的性能表现, 可以通过一下方法进行查看
linux 命令
grafana等监控工具
Jmeter可搭配PerMon Metrics Collector
这里主要介绍Linux命令
CPU利用率/负载
概念
CPU利用率: 程序对cpu时间片的占用情况,即表征CPU被用了多少
CPU负载: CPU使用队列的长度, 是一段时间内CPU正在处理和等待处理的进程数只和的统计信息,即表征CPU有多少活要干
Top命令解读
>>>> top
top - $当前时间 up $运行时间, $当前登录用户数, load average: $1min任务长度,$5min任务长度,$15min任务长度
Tasks: $进程数统计
%Cpu(s): $用户占比, $系统占比, $用户优先级更改占比, $空闲占比, $等待占比, $硬中断(Hardware IRQ)占用CPU的百分比,软中断(Software Interrupts)占用CPU的百分比, %虚拟机占比
Kib Mem: $内存总览, $空闲内存, $已使用内存, $内核缓存内存
Kib Swap: $交换区总量, $空闲交换区总量, $已使用交换区总量
... $进程信息
参照: (91条消息) linux top命令详解(看这一篇就够了)_Steven.1的博客-CSDN博客_linux top
其他命令
查看CPU核心数
cat /proc/cpuinfo准过标准
| CUP负载 | CPU使用率 | 评级 |
|---|---|---|
| 0.7*核心数 | <70% | 好 |
| 1*核心数 | <80% | 一般 |
| 1.5*核心数 | <85% | 差 |
| 2*核心数 | >85% | 很差 |
内存swap
概念
内存使用率: 即物理内存已使用区域对总内存的占比
swap: 磁盘上的一个特殊区域, 物理内存紧张是,会将不长访问的数据放到swap中. 由于磁盘IO的影响, 频繁进行swap说明内存使用紧张, 系统性能也会因为swap造成严重的影响
Linux中主要使用Top和free命令查看
free命令
free -wh # human_readable展示内run, 并且展示cashe
>>>
total used free shared buffers cache available
Mem: 3.6G 209M 2.2G 520K 301M 908M 3.2G
Swap: 0B 0B 0B
准过标准
内存利用率< 70% 且Swap基本无使用
| 内存利用率 | SWAP使用率 | 评级 |
|---|---|---|
| <70% | <30% | 好 |
| 70%-90% | 30%-60% | 一般 |
| >90% | > 60% | 差 |
性能分析
操作系统为了最大化利用内存,一般都设置大量的 cache,因此,内存利用率高达 99%并不是问题,内存的问题主要看某个进程占用的内存是否非常大以及是否有大量的swap(虚拟内存交换)。
- 使用top及ps命令确认占用大量内存的线程, 并通知开发
磁盘IO
概念
磁盘IO指的是服务器对磁盘进行数据的读取和写入
由于读写磁盘的消耗较大, 过高的磁盘IO会影响系统整体性能
一般使用iostat命令查看磁盘IO情况
iostat命令详解
使用iostat -xk查看磁盘io状况, 我们关心2个指标
iowait% 表示CPU等待IO时间占整个CPU周期的百分比
%util表示磁盘忙碌的情况
iostat -xk
>>> Linux 3.10.0-1160.62.1.el7.x86_64 (VM-4-7-centos) 2023年02月22日 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
3.82 0.00 1.11 0.12 0.00 94.95
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.01 3.99 0.57 3.58 9.99 33.21 20.83 0.02 3.92 5.21 3.72 0.98 0.40
scd0 0.00 0.00 0.00 0.00 0.00 0.00 7.20 0.00 0.57 0.57 0.00 0.57 0.00准过标准
| iowait% | %util | 评级 |
|---|---|---|
| <30% | <70% | 好 |
| <40% | – | 一般 |
| >50% | – | 差 |
其他命令
df -h # 查看文件系统磁盘空间网络IO
我们在进行容量预估时需要的是峰值带宽,即必须要保证站点在峰值流量时能够正常运转。假设,峰值流量是平均流量的5倍,这个5倍称为峰值因 子。
带宽要大于日常峰值流量
每秒处理请求数QPS
概念
服务器或服务器集群 单位时间内 处理请求的数量
服务器集群 一般指多个提供相同服务的服务器的集合; 不同服务的服务器集群应该分开统计
监控方式
- grafana工具监控
- 手动监控-日志
- 开发修改代码: 每次请求在日志添加一次标记
- 统计日志数量: 压测完后, 统计日志中, 标记数量和请求时间的趋势变化图, 即为QPS趋势图
- 手动监控-Tomcat access日志: Tomcat服务器可用, 参照Reference-面试官之问
准过标准
无准确标准, 一般用于开发优化 性能的参照
大型应用一般可以做到2000qps