如果你对性能测试感兴趣,但是又不熟悉理论知识,可以看下面的系列文章
https://www.cnblogs.com/poloyy/category/1620792.html
通常我们会从两个层面定义性能场景的需求指标,它们有映射关系,技术指标不能脱离业务指标
指同一个时间点执行相同的操作(如:秒杀)
高速公路上,同时有多少辆车经过同一个关卡,但不一定是同一个牌子的汽车
同一时间点,发出请求的用户数,一个用户可以发出多个请求
假设有 10 个用户数,每个用户同一时间点内发起 2 个请求,那么服务器收到的请求并发数就是 20
jmerter 中,默认一个接口请求,就是一个事务;但也支持多个接口整合成一个事务
若一个业务或事务有多个接口,那么多个单接口的性能指标值相加 ≠ 业务或事务的性能指标值
概念:从发起请求到收到请求响应的时间
包含:Request Time 和 Response Time
等价:发起请求网络传输时间 + 服务器处理时间 + 返回响应网络传输时间
在做性能测试时,要尽可能的降低网络传输时间,这样最终得出的 RT 会无限接近服务器处理时间,所以我们要把网络环境搞好
完成单个事务所用的时间,可能包含了多个请求
服务器每秒处理事务数,衡量服务器处理能力的最主要指标
如果要单独测试接口 1、2、3,那么 T 就是接口级
如果从用户角度下订单,那 1、2、3 都在一个 T 中,就是业务级
结合实际业务设计,库存服务一定是同步,而积分服务可以是异步,所以这个下单业务,可以只看作由 1、2 这两个接口组成,但是 3 接口还是要监控分析的
所以,性能中 TPS 中 T 的定义取决于场景的目标和 T 的作用
——事务 start(接口 1)
接口 1 脚本
——事务 end(接口 1)
——事务 start(接口 2)
接口 2 脚本
——事务 end(接口 2)
——事务 start(接口 3)
接口 3 脚本
——事务 end(接口 3)
——事务 start(业务 A)
接口 1 脚本 - 接口 2(同步调用)
接口 1 脚本 - 接口 3(异步调用)
——事务 end(业务 A)
——事务 start(业务 A)
点击 0 - 接口 1 脚本 - 接口 2(同步调用)
点击 0 - 接口 1 脚本 - 接口 3(异步调用)
——事务 end(业务 A)
一般情况下,我们会按从上到下的顺序一一来测试,这样路径清晰地执行,容易定位问题
每秒请求数,用户从客户端发起的请求数
对于请求数来说,也要看是哪个层面的请求,把上面的图做一点点变化来描述请求数
如果一个用户点击了一次,发出来 3 个 HTTP Request,调用了 2 次订单服务,调用了 2 次库存服务,调用了 1 次积分服务
问:Request 数量如何计算
答:3+2+2+1 = 8?不, 应该是 3,因为发出了 3 个 Request,而调用服务会有单独的描述,以便做性能统计
上图的订单服务、库存服务、积分服务,各调用了2、2、1次,还是比较好理解的
有很多维度可以衡量一个系统的性能能力,但是如果把五个指标同时都拿来描述系统性能能力的话,未必太混乱了
单位时间内,网络处理的请求数量(事务/s)
网络没有瓶颈时,吞吐量≈TPS
单位时间内,在网络传输的数据量的平均速率(kB/s)
结尾
本篇博文,部分参考了高老师的《性能测试实战30讲》,因为指标那一块讲的特别好哦~