通过Forcebot压测实践简述“并发模式”与“RPS模式”两种模式的区别

京东云开发者
• 阅读 82

作者:京东零售 张强

导读

本文主要讲解了Forcebot压测平台之中“并发模式”与“RPS模式”两种模式对于服务端性能指标的影响。通过“商品查询标签”的压测作为具体实践案例,简要阐述了“并发模式”与“RPS模式”两种模式压测过程中TPS、TP99以及TP999差异性。希望通过本文,读者可以对“并发模式”与“RPS模式”两种模式相关概念有更清晰的认识,并且能够将它们应用到具体的业务场景之中,帮助大家在实际代码研发、压测的时候,提供一些参考思路。

1、背景

****互联网的头部公司,对于接口服务性能要求非常高,各个应用链路之间接口要求TP99响应时间在100ms以下,甚至还有要求TP999。为了达到此目标需要不断的优化接口逻辑性能和服务器性能。基于此前提之下,最近开发了一个“商品查询标签”杰夫接口(RPC),外部门要求单机200QPS、TP999响应时间要小于40ms。我们在整个压测过程中采用了“并发模式”与“RPS模式”两种模式,但是它们给出的展现效果有一定差异性。其中“并发模式”适用于摸底业务系统各节点能同时承载的在线用户数,“RPC模式”适用于衡量系统的吞吐能力。

2、并发模式 (虚拟用户模式)

“并发”是指虚拟并发用户数,从业务角度,也可以理解为同时在线的用户数。 适用场景:如果需要从客户端的角度出发,摸底业务系统各节点能同时承载的在线用户数,可以使用该模式设置目标并发。以下是通过并发模式(虚拟用户模式)简单的请求流程图:

 通过Forcebot压测实践简述“并发模式”与“RPS模式”两种模式的区别 

综上所述:

****1)发压机按照设置的并发数 ,持续向目标服务端发起请求,经过网络传输杰夫线程池后,到达具体的方法内部执行逻辑。

2)压力机监控的性能指标(TP99、TP999)的总时长为网络传输耗时、杰夫线程等待耗时和方法耗时三者相加。

3)压力机监控的TPS指标为单位时间内持续发出的请求总和。

实践案例:

forcebot监控( 并发用户数:1;TPS平均:330;TP99:4ms;TP999:5ms

通过Forcebot压测实践简述“并发模式”与“RPS模式”两种模式的区别



umpkey监控( QPS:300;TP99:1ms;TP999:1ms

 通过Forcebot压测实践简述“并发模式”与“RPS模式”两种模式的区别

3、RPS模式

RPS(Requests Per Second)是指每秒请求数。 适用场景:RPS模式即“吞吐量模式”,通过设置每秒发出的请求数,从服务端的角度出发,直接衡量系统的吞吐能力,免去并发到RPS的繁琐转化一步到位。以下是通过RPS简单的请求流程图:

 通过Forcebot压测实践简述“并发模式”与“RPS模式”两种模式的区别 

综上所述:

****1)发压机按照设置的并发数 同时向目标服务端发起请求,经过网络传输和杰夫线程池后,到达具体的方法内部执行逻辑。

2)压力机监控的性能指标(TP99、TP999)的总时长为网络传输耗时、杰夫线程等待耗时和方法耗时三者相加。

3)压力机监控的TPS指标为单位内一次性发出的请求数量

实践案例:

forcebot监控( 并发用户数:50;TPS平均:47;TP99:6ms;TP999:60ms

 通过Forcebot压测实践简述“并发模式”与“RPS模式”两种模式的区别

umpkey监控( QPS:50;TP99:1ms;TP999:1ms



通过Forcebot压测实践简述“并发模式”与“RPS模式”两种模式的区别 

4、总结

****经过“并发模式”与“RPS模式”两种模式实践应用数据的对比,总结出以下经验可以供大家参考。希望此文对大家后续做服务接口性能压测有一定的帮助和启发。

1)“并发模式”并发用户数少于“RPS模式”并发用户数,但是forcebot压测事务对应TPS(最大/平均)的数量前者大于后者以及服务端UMP监控到QPS也是前者大于后者。

具体原因:“并发模式”是按照预先设置并发用户数持续不断的发送请求,所以在秒级收到的请求数量总和为QPS。然而“RPS模式”是按照预先设置并发用户数同时一次性将请求发出,并且秒级时间范围内不持续。所以它的秒级QPS只是这一次发出请求数量。

2)“并发模式”的并发用户数少于“RPS模式”的并发用户数并且服务端收到QPS前者大于后者的前提之下,forcebot压测事务对应TP99/TP999的性能指标前者优于后者。

具体原因:“并发模式”的并发用户数少于“RPS模式”的并发用户数,同时能够到达杰夫线程池的任务数前者少于后者,所以杰夫线程池任务缓冲区处于等待的任务就相对较少、等待时间较短。最终计算TP99/TP999性能的时候,“并发模式”的性能更优于“RPS模式”的性能。

3)“并发模式”和“RPS模式”方法内部UMP监控的时候,可用率、TP99和TP999等性能指标都远远优于forcebot压测事务监控指标。

具体原因:压测请求传输过程中,会经过跨网络传输、杰夫线程池等重要节点,这两个节点的耗时对于forcebot压测事务监控指标也有非常大的影响。例如:服务端的young gc或full gc等都会影响到杰夫线程的暂停,导致最终forcebot压测事务监控指标远远高于实际方法内部UMP监控到的值。

点赞
收藏
评论区
推荐文章
京东物流常态化压测实践 | 京东云技术团队
大促备战压测备战时间紧、任务多,压测备战压力较大,在大促备战多专项并行资源紧张情况下,频繁的系统调优给整个大促带来不可控的风险因素。引入常态化压测的手段,通过每周或每月的定期压测行为,持续把控系统性能表现,保证服务稳定性;同时将需求上线引起的性能问题前置暴露,及时定位优化问题;减轻备战压力,提升压测效率。
架构师日记-深入理解软件设计模式 | 京东云技术团队
本文从设计模式与编程语言的关系,设计模式与架构模式的区别,设计原则和设计模式的关系等几个维度进行了分析和解答。关于设计模式应该如何学习和应用的问题,给出了学习意见和实践心得。
Wesley13 Wesley13
3年前
MySQL 5.6.35 索引优化导致的死锁案例解析
一、背景随着公司业务的发展,商品库存从商品中心独立出来成为一个独立的系统,承接主站商品库存校验、订单库存扣减、售后库存释放等业务。在上线之前我们对于核心接口进行了压测,压测过程中出现了MySQL5.6.35死锁现象,通过日志发现引发死锁的只是一条简单的sql,死锁是怎么产生的?发扬技术人员刨根问底的优良传统,对于这次死锁原因进行了细致的排
Wesley13 Wesley13
3年前
mysql压测实战
1、安装压测工具curlshttps://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh|sudobashyumyinstallsysbench2、执行压测命令sysbenchdb
Stella981 Stella981
3年前
Jmeter28:linux下实现压测
jmeter单机压测命令行模式html报表生成控制台参数优化一/准备工作1.压力机安装并配置好jdk2.调试好程序脚本再上传到linux下3.进入jmeter bin目录执行     chmodx./\  可执行权限二/单机执行步骤执行./jmeter.shnt/expor
Stella981 Stella981
3年前
OceanBase数据库实践入门——性能测试建议
概述本文主要分享针对想压测OceanBase时需要了解的一些技术原理。这些建议可以帮助用户对OceanBase做一些调优,再结合测试程序快速找到适合业务的最佳性能。由于OceanBase自身参数很多、部署形态也比较灵活,这里并没有给出具体步骤。数据库读写特点压测的本质就是对一个会话的逻辑设计很高的并发。首先需要了解单个会话在
京东云开发者 京东云开发者
11个月前
谈谈压测方案的那点事 | 京东物流技术团队
前言在现阶段大促备战的压测不算是一件新鲜事,已经不存在什么技术瓶颈或者资源问题,每个团队都有很多人能够执行性能测试,在一些团队也已经落地了日常常态化,但压测也没有简单到只在压测平台上设置参数、运行脚本,然后去看压测报告中某个指标是否满足压测目标那么简单,我
京东云开发者 京东云开发者
11个月前
大数据平台红蓝对抗 - 磨利刃,淬精兵! | 京东云技术团队
一、背景目前大促备战常见备战工作:专项压测(全链路压测、内部压测)、灾备演练、降级演练、限流、巡检(监控、应用健康度)、混沌演练(红蓝对抗),如下图所示。随着平台业务越来越复杂,红蓝对抗的作用愈来愈明显,下面将详细介绍大数据平台在本次双十一大促备战工作中是
京东云开发者 京东云开发者
9个月前
大数据平台红蓝对抗 - 磨利刃,淬精兵!
背景目前大促备战常见备战工作:专项压测(全链路压测、内部压测)、灾备演练、降级演练、限流、巡检(监控、应用健康度)、混沌演练(红蓝对抗),如下图所示。随着平台业务越来越复杂,红蓝对抗的作用愈来愈明显,下面将详细介绍大数据平台在大促备战工作中是如何开展红蓝对
京东云开发者 京东云开发者
5个月前
通过MVEL表达式和Apache Chain职责链模式解耦MQ消息处理节点的实践应用
导读本文主要讲解了MVEL表达式和责任链设计模式相结合一起的消息处理解决方案设计、解耦消息处理节点以及方便代码维护扩展。通过“订单拆单消息”的接入作为具体实践案例,简要阐述了MVEL表达式和ApacheChain职责链设计模式应用场景。希望通过本文,读者可