通过压测表格讨论并发量、RT、QPS量化关系

欢迎大家关注公众号「JAVA前线」查看更多精彩分享文章，主要包括源码分析、实际应用、架构思维、职场分享、产品思考等等，同时欢迎大家加我微信「java_front」一起交流学习

1 一个公式

1.1 基本内容

一个公司有7200名员工，每天上班打卡时间是早上8点到8点30分，每次打卡时间系统执行时长5秒，那么RT、QPS、并发量分别是多少？

RT表示响应时间，问题已经包含答案：

• RT = 5秒

QPS表示每秒访问量，假设签到行为平均分布：

• QPS = 7200 / (30 x 60) = 4

并发量表示系统同时接受请求数：

• 并发量 = QPS x RT = 4 x 5 = 20

根据上述实例引出公式：

• 并发量 = QPS x RT

1.2 如何理解

看到上述公式不禁产生疑问：并发量居然和RT成正比，难道RT越高并发量越大？这明显与生产实践相违背。我们应该这样理解：

• 并发量是施加于系统之压力
• 当系统处于压力且正常工作时，满足公式
• 当压力发生变化时，公式中各项会发生变化
• 当压力达到一个临界点，不再满足上述公式
• 通过实验可以观察公式中各项变化

2 压力测试

2.1 测试代码

2.1.1 参数实体

publicclassBizParamDTO{privateString field;}

2.1.2 业务服务

publicinterfaceEService{publicStringe1(BizParamDTO param)throwsException;}@ServicepublicclassEServiceImplimplementsEService{@OverridepublicStringe1(BizParamDTO param)throwsException{System.out.println(Thread.currentThread().getName()+",e1 param="+ param);TimeUnit.MILLISECONDS.sleep(100);return param.getField();}}

2.1.3 访问端点

@RestController@RequestMapping("/test")publicclassBizController{@ResourceprivateEService eservice;@PostMapping("/biz4")publicbooleanbiz4(@RequestBodyBizParamDTO param)throwsException{
        eservice.e1(param);returntrue;}}

2.2 压测思路

2.2.1 压测工具

JMeter

2.2.2 调整指标

线程数从50上升至10000，压力持续1分钟

2.2.3 观察指标

平均耗时、耗时95Line、错误率、吞吐量

2.2.4 对应关系

• 并发量 = 线程数
• RT = 平均耗时
• QPS = 吞吐量

2.3 压测分析

2.3.1 压测结果

压测结果如下表，我们可以从三个维度分析：

2.3.1 阶段一：QPS上升

• 线程数50-200阶段：RT不变，QPS上升
• QPS可以理解为系统处理能力
• 面对上述压力，系统完全可以应对
• 符合公式：并发量 = QPS x RT

2.3.2 阶段二：RT上升

• 线程数200-6000阶段：RT上升，QPS不变
• RT响应时间越来越慢
• 面对上述压力，系统应对有些吃力
• 符合公式：并发量 = QPS x RT

2.3.3 阶段三：系统崩溃

• 线程数7000-10000阶段：错误率显著上升
• 面对上述压力，系统已经无法应对
• 不符合公式：并发量 = QPS x RT

2.4 分析小结

• 压力上升初期，系统应对自如，QPS上升
• 压力上升中期，系统对应吃力，RT上升
• 压力上升后期，系统无法对应，错误率上升

3 非线性

3.1 生活场景

我们从非线性这个概念理解压测结果，这个概念无处不在。

你要赶早上8点钟的火车，如果6:30出发可以在7:00到达车站，你得到一个结论：只要30分钟就可以到达车站。你早上想睡晚一点预计7:10出发，预计7:40可以到达车站。

但是最可能的结果是你会错过这趟火车。因为正好遇上早高峰，堵车导致至少需要花费1个小时才能到达车站。

一个雪球重量是100克，打雪仗时被砸中100次不会造成任何影响。但是如果被10公斤的雪球砸中1次，这可能会造成严重的伤害。

事物不是简单线性关系，达到临界值时会造成截然不同之结果。

3.2 秒杀场景

假设秒杀系统当每秒30个人访问时，响应时间是10毫秒。即从用户点击按钮至得到结果这个过程只需10毫秒性能不错，根据上述指标设计：

• 每秒30访问量响应时间10毫秒
• 每秒300访问量响应时间100毫秒
• 每秒3000访问量响应时间1000毫秒

如果按照这个思路做系统设计将会发生重大错误。因为当每秒3000个访问量发生时，系统可能直接崩溃，无法再处理任何请求。

4 文章总结

第一章介绍了一个公式，定量描述了并发量、RT、QPS三者关系，并阐述了应该如何理解这个公式和适用场景。

第二章对系统进行了压测，线程数从50到10000不断上升，使用表格记录了不同压力下系统表现，展示并发量、RT、QPS如何变化。

第三章介绍了非线性概念，技术系统不是简单线性关系，达到临界值时会造成截然不同之结果。

5 扩展阅读

通过压测讨论应该如何设置线程数

一个公式说明DUBBO线程池打满原因

欢迎大家关注公众号「JAVA前线」查看更多精彩分享文章，主要包括源码分析、实际应用、架构思维、职场分享、产品思考等等，同时欢迎大家加我微信「java_front」一起交流学习