作者：汽车事业产研 张强
导读
本文主要讲解了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监控到的值。