作者:京东零售 张强
导读
本文主要讲解了Forcebot压测平台之中“并发模式”与“RPS模式”两种模式对于服务端性能指标的影响。通过“商品查询标签”的压测作为具体实践案例,简要阐述了“并发模式”与“RPS模式”两种模式压测过程中TPS、TP99以及TP999差异性。希望通过本文,读者可以对“并发模式”与“RPS模式”两种模式相关概念有更清晰的认识,并且能够将它们应用到具体的业务场景之中,帮助大家在实际代码研发、压测的时候,提供一些参考思路。
1、背景
****互联网的头部公司,对于接口服务性能要求非常高,各个应用链路之间接口要求TP99响应时间在100ms以下,甚至还有要求TP999。为了达到此目标需要不断的优化接口逻辑性能和服务器性能。基于此前提之下,最近开发了一个“商品查询标签”杰夫接口(RPC),外部门要求单机200QPS、TP999响应时间要小于40ms。我们在整个压测过程中采用了“并发模式”与“RPS模式”两种模式,但是它们给出的展现效果有一定差异性。其中“并发模式”适用于摸底业务系统各节点能同时承载的在线用户数,“RPC模式”适用于衡量系统的吞吐能力。
2、并发模式 (虚拟用户模式)
“并发”是指虚拟并发用户数,从业务角度,也可以理解为同时在线的用户数。 适用场景:如果需要从客户端的角度出发,摸底业务系统各节点能同时承载的在线用户数,可以使用该模式设置目标并发。以下是通过并发模式(虚拟用户模式)简单的请求流程图:
综上所述:
****1)发压机按照设置的并发数 ,持续向目标服务端发起请求,经过网络传输和杰夫线程池后,到达具体的方法内部执行逻辑。
2)压力机监控的性能指标(TP99、TP999)的总时长为网络传输耗时、杰夫线程等待耗时和方法耗时三者相加。
3)压力机监控的TPS指标为单位时间内持续发出的请求总和。
实践案例:
• forcebot监控( 并发用户数:1;TPS平均:330;TP99:4ms;TP999:5ms )
•umpkey监控( QPS:300;TP99:1ms;TP999:1ms )
3、RPS模式
RPS(Requests Per Second)是指每秒请求数。 适用场景:RPS模式即“吞吐量模式”,通过设置每秒发出的请求数,从服务端的角度出发,直接衡量系统的吞吐能力,免去并发到RPS的繁琐转化一步到位。以下是通过RPS简单的请求流程图:
•综上所述:
****1)发压机按照设置的并发数 , 同时向目标服务端发起请求,经过网络传输和杰夫线程池后,到达具体的方法内部执行逻辑。
2)压力机监控的性能指标(TP99、TP999)的总时长为网络传输耗时、杰夫线程等待耗时和方法耗时三者相加。
3)压力机监控的TPS指标为单位内一次性发出的请求数量。
•实践案例:
•forcebot监控( 并发用户数:50;TPS平均:47;TP99:6ms;TP999:60ms )
•umpkey监控( QPS:50;TP99:1ms;TP999:1ms )
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监控到的值。