并发模式与 RPS 模式之争，性能压测领域的星球大战

本文是《如何做好性能压测》系列专题分享的第四期，该专题将从性能压测的设计、实现、执行、监控、问题定位和分析、应用场景等多个纬度对性能压测的全过程进行拆解，以帮助大家构建完整的性能压测的理论体系，并提供有例可依的实战。

该系列专题分享由阿里巴巴 PTS 团队出品，欢迎在文末处加入性能压测交流群，参与该系列的线上分享。

第一期：《压测环境的设计和搭建》，点击这里。
第二期：《性能压测工具选型对比》，点击这里。
第三期：《阿里巴巴在开源压测工具 JMeter 上的实践和优化》，点击这里。

1996年， LR 4.0 版本发布，将性能测试专业理论工具化、产品化，这直接影响之后20多年性能测试领域的理论基础。但是 LR 作为一款商业化产品，因其价格昂贵，推广和传播受限。1998年底，JMeter 开源 ，并发布1.0版本，性能测试领域逐渐蓬勃发展起来。

Loadrunner、Jmeter 引领了性能测试领域的一个时代，功能强大，脚本化，扩展性强，将性能测试标准化、专业化，后续几乎所有性能测试工具或者商业化产品都马首是瞻。本文就性能测试做了一个纯YY的“实践”（真的只是纯理论分析！），有一些不一样的思路跟大家一起探讨下，望轻踩。

前言：并发、RPS 和 RT

接触性能测试的同学要理解的概念有非常多，在正文之前先跟大家就几个核心指标统一下口径：

• 并发用户、并发、VU：一般用来表示虚拟用户（Virutal User，简称VU），对应到 Jmeter 的线程组线程，对应到 Loadrunner 的并发 Concurrency ，在本文都是一个意思。
• 每秒发送请求数、RPS：指客户端每秒发出的请求数，有些地方也叫做QPS，本文不单独讨论“事务”所以可以近似对应到Loadrunner的TPS（Transaction Per Second, 每秒事务数），本文统一叫做 RPS。
• 响应时间、RT：对，没错，这个就是你理解的那个意思，从发起请求到完全接收到应答的时间消耗。

根据“Little定律”，在平衡状态下，我们可以等价认为并发、RPS 和 RT 之间的关系可以概括为：并发数 = RPS * 响应时间