本文是《如何做好性能压测》系列主题分享的第四期，该主题从性能压力测量的设计、实现、执行、监测、问题定位与分析、应用场景等多个纬度分解性能压力测量的全过程，由大家构建完整的性能压力测量理论体系，提供有实例的实战
这个系列的主题共享是阿里巴巴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 (transactionpersection ) (传输请求数) 本文将与RPS进行统一。 响应时间，RT :是的。 是的。 这是你理解的那个意思。 从提出请求到完全收到响应的时间消耗。 根据“Little定律”，可以等价地认为在平衡状态下，同时，RPS、RT的关系为同时数=RPS *响应时间
如果偷懒了，就当做性能测试领域的“乘法诀窍”，直接背吧。 他会帮助你迅速理解很多问题； 如果您想详细了解具体原理，请阅读Eric Man Wong于2004年发表的文章《Method for Estimating the Number of Concurrent Users》。 这是等价的。
100工人的问题
如果您还不了解“RT对并发模式性能测试的影响”，或者有疑问，强烈建议您读完本节。 如果你不想了解细节，可以直接跳到这一节的结尾看结论； 如果您充分了解，可以直接跳过这一部分。
首先，让我们从众所周知的例子开始。 假设有一条生产这种箱子的流水线，配置了100名工人。 条件如下。
100名工人的身体素质一模一样，因此生产力可以近似为只与工作复杂性有关； 该流水线有3个工作(下图所示的节点a、节点b、节点c )，所有工人都能够胜任； 节点a的工人装箱需要平均时间RT1=0.5s (秒，节点b的工人装箱需要平均时间RT2=3s )秒，节点c的工人装箱需要平均时间RT3=1.5s )秒； 同一箱子必须按照节点a、节点b、节点c的顺序包装。 问：节点a、节点b、节点c分别配置多少工人x、y、z，这条流水线就能达到最大的生产能力，从而求得流水线的最大生产能力T/s？ (下图)
在平衡的状态下，我们从宏观的角度分析，整条流水线包装完一个箱子的总时间=(0.5 )3) 1.5 ) s，可以很容易地获得流水线的生产能力。
流水线的生产能力t=100/(0.5 )3) 1.5 )=20 /s
很多人可能有疑问，“平衡状态是什么？ ”这可以理解为，主管非常睿智地安排各节点之间的劳动者分配，让所有劳动者都能做些什么，也不会让劳动者忙不过来。 从微观角度看，如果节点之间的产能不一致，有些节点会等待箱子处理，而有些节点的工人会等待箱子。 因此，可以得出在平衡状态下，所有节点的生产能力一定是一致的。
t(a )=t ) b )=t )=T=20 /s
因此，根据Little定律，可以推断各节点的人员(vu )被分配。
x=t(a ) RT1=20 0.5=10
y=t(b ) rt2=20 )3=60
z=t(c ) rt3=20 )1.5=30
下面的Jmeter图，我相信大家可以很容易地找到前面的自助和对照关系，在这里不做说明。
生产能力=RPS
工人=同时
完成平均时间RT=响应时间，rt(rt ) )
src="https://p26.toutiaoimg.com/origin/pgc-image/a0c69558d2a54ffdb5763c8c15021594?from=pc">综上所述，我们可以得出两个结论：
在平衡状态下，所有节点的 RPS 必然一样。在平衡状态下，任意节点的 RT 都会影响整体 RPS ，进而会影响并发在节点之间的分配关系。为了描述方便，我们将节点A、节点B和节点C组成的“100人的流水线”叫做“串联链路”。
节点A的RPS = 节点B的RPS = ... = 串联链路RPS
串联链路RPS = 并发数 / (RT1 + RT2 + ... )
节点N的并发数 = RTn 节点N的RPS = RTn 串联链路RPS
你确定考虑全面了吗？
控制并发是目前最为普遍被使用到的压测模式，打个比方，有一个网站大概会在 下周一10:00 预估有 10w人同时访问，那么为了保障网站的问题，很自然的想到使用10w个并发来压测下整个网站的接口，对应到 JMeter 即为设置线程组的线程数，对应到 LoadRunner 设置 VU（Visual User）数，很容易理解。
另外，我从阿里云PTS官方拿到近6个月的数据显示，选择并发模式与RPS模式分别占比 89%与11%，并发模式占据绝对的规模优势。
但是，如果你已经充分了解了“RT对于固定并发模式的性能测试的影响”，这里我不禁要问一句（邪恶脸）“Emm... 你有想过类似Jmeter、LR等并发模式压测工具拿到的结果是真实的吗？准确吗？”。
下面我要讲一个“恐怖故事”，先来看一张相对抽象的环境结构图，
在平衡状态下，已知总并发VU，以及 接口1、接口2、接口3 的响应时间分别为RT1、RT2、RT3，通过前面的理论基础，我们可以轻易地写出下面的算式：
T = RPS1 = RPS2 = RPS3 = VU / (RT1 + RT2 + RT3)
接口1的并发 X = T * RT1
接口2的并发 Y = T * RT2
接口3的并发 Z = T * RT3
分析下接口的RT的构成，大致概括为下面5部分：
压测工具耗时：这个很好理解，压测工具在发送请求之前会做参数的拼装/替换、下载应答报文、解析应答报文（断言）等都是需要耗费时间的，一般情况下压测工具的时间消耗会非常低，可以忽略。但是对于报文较大或者断言较复杂的情况下，压测工具耗时过大也会出现瓶颈；网络时间：一般来说在 VPC/IDC 内部的网络消耗非常低，所以我们可以近似地认为网络时间消耗都来源于运营商网络。同样，对于接口的请求和应答报文比较大的情况下，不论是运营商网络还是内网网络的带宽都更容易出现瓶颈；安全、鉴权、负载均衡模块耗时：这一块的时间消耗一般来说相对较低，受限于连接数、带宽等，可能会出现由于配置问题，比如连接数上限超过预期，则会造成等待建连超时；应用业务处理耗时：一般情况下，应用业务处理耗时占据 RT 的百分比最高，也是一般我们可以通过优化提高吞吐量的重点区域。可能包含 应用之间 RPC 服务调用、数据库SQL执行、读写缓存、读写消息等。第三方依赖耗时：这里就复杂了，各种情况都有，你可以完全信赖或者完全不信赖它的稳定性。一般它的RT评估有相关 SLA 的要求，一般压测实施的时候根据 SLA 约定的 RT 要求，mock 掉第三方接口依赖，正式压测的时候再一起联压。更进一步，可以得出这样的结论，在并发模式下，影响压测结果以及应用服务器的吞吐量的因素有：
压测工具的性能网络状态接入层配置和性能应用服务性能第三方依赖的 SLA...因此，出现了一种混沌状态，可能由于压测工具所在宿主机负载变化、网络环境变化、应用服务性能优化或者劣化等因素的干扰，拿着相同的脚本进行了10次，每次得到的接口 RPS 都不一样，服务器端的压力也不一样，但是从表象来看，一切正常，但这样的性能测试并不能真实反映任何问题，也并不能指导运维做出正确容量规划的决策。因为影响 RT 的因素实在是太多太多了，任何客观因素的影响都直接影响测试结果的准确性。
并发模式 = 性能瓶颈“定性”分析
在这里，我更愿意定义并发模式性能测试为一种性能瓶颈分析的定性工具，在尽量相同的条件下经过反复测试，通过分析各个接口的RT构成找到“相对的”性能瓶颈。但是大家有没有想过，将所有接口优化到极限的性能之后，可以拍胸脯说“我们的系统已经可以抗住 XXX 并发用户量的访问了”吗？答案是否定的，原因有三：
不真实，主要体现在 ① 环境不真实；② 压测（脚本）模型不真实；主体错误，并发只是一个诱因和触发器，影响性能的主体是服务端的RPS；并发测试的效果真实性依赖于RT，而RT的构成异常复杂。对了，前面的分析漏了一个影响并发性能测试结果的非常重要的因素：思考时间（用户在操作的时候，步骤之间用户会停顿一段时间）。思考时间的引入会将并发的建模的复杂度带到几乎不能实现的地步，因为它不像其他相对客观的因素，它是非常主观的。假如用户停留的时间很长，可能是因为感兴趣多看一会儿，或者页面上有100个表单需要填写，或者看不懂文案是啥意思正在 Google，或者...去冲咖啡了。
有人可能会追问“思考时间究竟要设置多少合适呢？”，我可以非常明确的说“不知道！”，如果你有时间，可以通过大数据 BI 分析统计学意义上的每个接口之间用户停顿的时间，然后将它设置上，假设每个接口的思考时间总和为 S=(S1+S2+S3)，那么我们可以更新下公式：
T = RPS1 = RPS2 = RPS3 = VU / (RT1 + RT2 + RT3 + S)
接口1的并发 X = T * RT1
接口2的并发 Y = T * RT2
接口3的并发 Z = T * RT3
可以看到，增加了思考时间之后，整体的吞吐量、所有接口的并发都下降了，因为有部分用户在“思考”。增加“思考时间”有助于提高并发模式下性能测试的准确性，除此之外，还有一些提高并发模式的准确性的手段：
压测工具地域定制、运营商定制增加条件跳转，模拟用户重试行为增加集合点...这些手段你可以非常轻易的在市面上的开源或者云测平台上找到（有些功能可能需要支付一些费用），在这里不再一一赘述，归根到底，可以总结为“优化接口 RT 使其接近真实值以提高并发模式的准确性”。
但并发模式始终都受制于“不稳定的”、“难模拟的”、“难预测的”接口 RT ，通过并发模式拿到指导运维进行容量规划的结果，是要付出的代价会非常大的，甚至也不能达到想要的结果。
在真实情况下，接口1、接口2、接口3的 RPS 是不一样的，抛开接口异常断言失败不继续调用后面的接口的情况，接口 RPS 关系是呈倒金字塔分布，比方说，浏览商品（接口）了之后不一定会去下单购买（接口），因为大家一般会反复浏览不同的商品选择最中意的再下单，所以浏览商品（接口）的 RPS 必然会比下单购买（接口）的 RPS 要高，用户有放弃继续“走下一步”的权利，但是这种情况你如果尝试对并发的分布来建模，是一个非常庞大且复杂工程问题，因为影响的因素实在太多了。
如下图所示，并发压测模式下，所有接口的 RPS 都是一样的，与“实际情况”（图右部分）大相径庭。
受传统性能测试思路的影响，目前有接近90%的企业用户（数据来源于 阿里云PTS ） 将并发模式性能测试的结果作为稳定性、容量验收的依据，所以说这是一件非常恐怖的事情。
容量规划：从定性分析到定量分析
在这里我非常乐意跟大家分享一份来源于 QA Intelligence《State of Testing™ Report 2019》关于2016~2019年软件开发模式的调查数据：
软件开发模式占比（2019、2018、2017、2016）
数据显示，DevOps 第一次超过 Waterfall（瀑布模式）成为第二位被越来越多的企业接受的开发模式，而瀑布模式等传统开发模式有逐渐退出历史舞台的趋势。敏捷开发和 DevOps 大行其道，开发、测试和运维等部门、角色之间需要有一种高效的沟通和协作手段。
想到了一句非常“肤浅”但有点道理的话，“性能问题优化之后最终都可以转化为容量问题”，简单地可以理解为测试同学发现了性能瓶颈，然后开发同学经过了优化，运维同学根据优化之后的系统的能力进行扩容或者缩容。瞧！这不就是开发、测试和运维完美协作的一个典型实践嘛？！
这个过程，我们叫做“容量规划”的实施过程，重点不是容量而是规划，如果成本不是任何问题，我们可以堆砌无限大的资源，用户体验会极其好，但是会造成极大的资源浪费。所以这里说的“容量规划”是在保证用户体验不受影响（稳定性）的前提下，使有限的资源的利用率最大化（成本）的方法论。打个比方，运维准备了100台机器，有5个应用，那么“怎么分配这100台机器给5个应用可以使系统既可以正常对外服务又可以使系统达到最大的吞吐量能力”就是容量规划要解决的问题。
容量规划的核心有一张已经用的“泛黄”的图，大家应该一看就明白，有两个核心指标：
预估的业务量级：对于单应用而言就是这个应用的RPS吞吐量峰值，这个数据一般可以来源于流量模型和历史数据沉淀；单台机器的能力值：在某一个流量模型下，单台机器系统水位达到安全水位时的RPS峰值。上面提到一个概念叫做“流量模型”，这个流量模型你可以近似的认为就是前面图中“实际情况”的 RPS 倒金字塔，他有两个要素：
接口范围每个接口的RPS容量规划的目的性非常强，也就是在特定“流量模型”下，给出资源分配的最优解。在压测实施的时候，压测的主体是接口的 RPS，按照流量模型进行试压。（如果你还在想为什么主体是 RPS 而不是并发的话，请在仔细阅读前面那章）
RPS 模式压测在容量规划的典型应用，是并发模式无法实现的。正式因为此，我们才能将性能测试从“定性分析”转化为“定量分析”。
阿里在2013年构建了一整套基于线上全链路压测的容量规划体系，逐渐替代之前单应用、单接口这种低效的容量评估手段，过程也是非常曲折的。容量规划是一个非常大的课题，本文的重点不是“容量规划”，如果你对“智能化全链路容量规划”感兴趣，请在文末留言或加入我们的性能压测交流钉群。
结尾：无意引战
并发模式与 RPS 模式压测各有各自的使用场景，并发模式更加适用于对于系统定性的分析，比如帮助定位性能瓶颈，单接口的性能基线沉淀（对比历史性能优化or劣化）；而 RPS 模式在对系统做定量的分析有杰出表现，比如容量规划、全链路性能基线沉淀，当然也可以帮助定位性能瓶颈。并发模式的难点在于 RT 的准确性拟真， RPS 模式的难点在于模型的准确性评估和预测，从实现难度上来说，前者相对于后者来说难度更大一些、掌控度更低一些。
当然，我无意引战，并发模式、RPS 模式、你想要的和你还没有想到未来想要的都可以在 阿里云PTS 上找到。
本文作者：不安的棒球，花名隐寒，阿里云PTS 高级技术专家，2014年加入阿里巴巴，一直从事性能测试和高可用领域的相关工作。