常见压力模式
并发模式(即虚拟用户模式)和RPS模式(即Requests Per Second,每秒请求数,吞吐量模式)。
本文介绍这两种压力模式的区别,以便根据自身业务场景选择更合适的压力模式。
并发模式
“并发”是指虚拟并发用户数,从业务角度,也可以理解为同时在线的用户数。
应用场景
如果需要从客户端的角度出发,摸底业务系统各节点能同时承载的在线用户数,可以使用该模式设置目标并发。
使用说明
并发模式下,需要指定全场景的最大并发数,再设置各串联链路的并发权重。
串联链路内各API的响应速度不同(表现为响应时间不同),所以单位时间内API的并发数也会不同。API响应速度越快,单位时间内累积在API上的并发用户数越少。
假设,目前共有100个虚拟用户需要操作某个事务(即串联链路)。该串联链路中共有2个API,API 1的响应速度快而API 2响应速度慢。则更多的虚拟用户将会等待在API 2上,API 2则需要更多的线程资源来处理更多的虚拟用户请求。
RPS模式
RPS(Requests Per Second)是指每秒请求数。
应用场景
RPS模式即吞吐量模式,通过设置每秒发出的请求数,从服务端的角度出发,直接衡量系统的吞吐能力,免去从并发到RPS的繁琐转化,可快速实现压测。
使用说明
API接口(如电商加购物车、下单等)主要用TPS(Transaction Per Second, 每秒事务数)来衡量系统的吞吐能力,选择该模式可以直接按照预期的TPS设置RPS。如果希望检验“下单”接口是否能达到500 TPS的预期,那么设置RPS为500,每秒发送500个请求,可检验系统的吞吐能力。
该模式下,请求无法及时响应时可能会导致较高的并发,异常情况请及时停止。
该模式仅支持非自动递增进行压测,即您需在压测过程中手工调速。具体操作,请参见手动调速模式下调速。
同一链路中,后一个API的RPS值需小于等于前一个API的RPS值。
基于实际业务考虑,一般正常业务链路转化模型应该为漏斗形状。例如,正常业务链路为:查看首页-查看商品详情-加入购物车-下单-付款。那么通常情况下,查看首页的用户数会比查看商品详情的用户数多,查看商品详情的用户数也会比加入购物车的用户数多,以此类推,所以后一个API的RPS值需小于前一个API的值,这样就比较符合漏斗模型。
配置量级及数据
设置好压测模式后,还需要在施压配置页面设置压测起始量级与最大量级。
压测数值
每个API可以视为业务系统的一个节点,处理能力不同导致可承载的业务量也不一致。并发模式与RPS模式施压的方式不同,故压测数值上的设置也会不同。
说明 无论选取何种压测模式,各场景最大值的总和不可超过该账户下对应资源包的最大VU、RPS。
两种模型的区别
RPS(Requests Per Second)压力模型和并发用户模型都是性能测试中常用的模型,但它们的测试方法和指标略有不同。
并发用户模型是一种测试方法,它通过模拟多个并发用户同时访问系统,以测试系统在高并发情况下的性能表现。测试人员可以逐步增加并发用户数,直到达到系统的瓶颈为止。在并发用户模型中,主要关注的指标是并发用户数、响应时间、吞吐量、错误率等。
RPS压力模型也是一种测试方法,它通过模拟多个并发用户向系统发送请求,以测试系统在高并发情况下的性能表现。测试人员可以逐步增加请求量,直到达到系统的瓶颈为止。在RPS压力模型中,主要关注的指标是每秒钟处理的请求数(即RPS)、响应时间、吞吐量、错误率等。
因此,两种模型的区别在于,对于同样的并发用户数,RPS模型可能会产生更多的请求量,而并发用户模型则更强调每个用户并发请求的情况。此外,两种模型对于测试系统性能的关注点也略有不同,但都是测试系统在高并发情况下的性能表现,以便找到系统瓶颈并进行优化。
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!