02丨性能综述：TPS和响应时间之间是什么关系？
下载APP
关闭
渠道合作
推荐作者
02丨性能综述：TPS和响应时间之间是什么关系？
2019-12-16 高楼 来自北京
《性能测试实战30讲》
课程介绍
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="1142" height="640"><rect fill-opacity="0"/></svg>)
讲述：高楼
时长16:02大小21.98M
我们在上一篇文章中讲了性能测试的概念，肯定会有人觉得，那些概念很重要，怎么能轻易抹杀呢？那么，在今天的文章中，我们就来扒一扒性能场景，看看概念与实际之间的差别。
前面我们说了性能要有场景，也说了性能场景要有基准性能场景、容量性能场景、稳定性性能场景、异常性能场景。在我有限的十几年性能生涯中，从来没有见过有一个性能场景可以超出这几个分类。下面我将对前面说到的概念进行一一对应。
学习性能的人，一定看吐过一张图，现在让你再吐一次。如下：
在这个图中，定义了三条曲线、三个区域、两个点以及三个状态描述。
三条曲线：吞吐量的曲线（紫色）、利用率（绿色）、响应时间曲线（深蓝色）。
三个区域：轻负载区（Light Load）、重负载区（Heavy Load）、塌陷区（Buckle Zone）。
两个点：最优并发用户数（The Optimum Number of Concurrent Users）、最大并发用户数（The Maximum Number of Concurrent Users）。
三个状态描述：资源饱和（Resource Saturated）、吞吐下降（Throughput Falling）、用户受影响（End Users Effected）。
我在很多地方，都看到了对这张图的引用。应该说，做为一个示意图，它真的非常经典，的确描述出了一个基本的状态。但是，示意图也只能用来做示意图，在具体的项目中，我们仍然要有自己明确的判断。
我们要知道，这个图中有一些地方可能与实际存在误差。
首先，很多时候，重负载区的资源饱和，和 TPS 达到最大值之间都不是在同样的并发用户数之下的。比如说，当 CPU 资源使用率达到 100% 之后，随着压力的增加，队列慢慢变长，响应时间增加，但是由于用户数增加的幅度大于响应时间增加的幅度之前，TPS 仍然会增加，也就是说资源使用率达到饱和之后还有一段时间 TPS 才会达到上限。
大部分情况下，响应时间的曲线都不会像图中画得这样陡峭，并且也不一定是在塌陷区突然上升，更可能的是在重负载区突然上升。
另外，吞吐量曲线不一定会出现下降的情况，在有些控制较好的系统中会维持水平。曾经在一个项目中，因为 TPS 维持水平，并且用户数和响应时间一直都在增加，由于响应时间太快，一直没有超时。我跟我团队那个做压力的兄弟争论了三个小时，我告诉他接着压下去已经没有意义，就是在等超时而已。他倔强地说，由于没有报错，时间还在可控范围，所以要一直加下去。关于这一点争论，我在后续的文章中可能还会提及。
最优并发数这个点，通常只是一种感觉，并没有绝对的数据用来证明。在生产运维的过程中，其实我们大部分人都会更为谨慎，不会定这个点为最优并发，而是更靠前一些。
最大并发数这个点，就完全没有道理了，性能都已经衰减了，最大并发数肯定是在更前的位置呀。这里就涉及到了一个误区，压力工具中的最大用户数或线程数和 TPS 之间的关系。在具体的项目实施中，有经验的性能测试人员，都会更关心服务端能处理的请求数即 TPS，而不是压力工具中的线程数。
这张图没有考虑到锁或线程等配置不合理的场景，而这类场景又比较常见。也就是我们说的，TPS 上不去，资源用不上。所以这个图默认了一个前提，只要线程能用得上，资源就会蹭蹭往上涨。
这张图呢，本来只是一个示意，用以说明一些关系。但是后来在性能行业中，有很多没有完全理解此图的人将它做为很有道理的“典范”给一些人讲，从而引起了越来越多的误解。
此图最早的出处是 2005 年 Quest Software 的一个 PSO Consultant 写的一个白皮书《Performance Testing Methodology》。在 18 页论述了这张图，原文摘录一段如下：
You can see that as user load increases, response time increases slowly and resource utilization increases almost linearly. This is because the more work you are asking your application to do, the more resources it needs. Once the resource utilization is close to 100 percent, however, an interesting thing happens – response degrades with an exponential curve. This point in the capacity assessment is referred to as the saturation point. The saturation point is the point where all performance criteria are abandoned and utter panic ensues. Your goal in performing a capacity assessment is to ensure that you know where this point is and that you will never reach it. You will tune the system or add additional hardware well before this load occurs.
按照这段描述，这个人只是随着感觉在描述一种现象，除此无它。比如说，The saturation point is the point where all performance criteria are abandoned and utter panic ensues. 在我的工作经验中，其实在 saturation point 之前，性能指标就已经可以显示出问题了，并且已经非常 panic 了，而我们之所以接着再加压力是为了让指标显示得更为明显，以便做出正确的判断。而调优实际上是控制系统在饱和点之前，这里有一个水位的问题，控制容量到什么样的水位才是性能测试与分析的目标。
我们简化出另一个图形，以说明更直接一点的关系。如下所示：
上图中蓝线表示 TPS，黄色表示响应时间。
在 TPS 增加的过程中，响应时间一开始会处在较低的状态，也就是在 A 点之前。接着响应时间开始有些增加，直到业务可以承受的时间点 B，这时 TPS 仍然有增长的空间。再接着增加压力，达到 C 点时，达到最大 TPS。我们再接着增加压力，响应时间接着增加，但 TPS 会有下降（请注意，这里并不是必然的，有些系统在队列上处理得很好，会保持稳定的 TPS，然后多出来的请求都被友好拒绝）。
最后，响应时间过长，达到了超时的程度。
在我的工作中，这样的逻辑关系更符合真实的场景。我不希望在这个关系中描述资源的情况，因为会让人感觉太乱了。
为什么要把上面描述得如此精细？这是有些人将第一张图中的 Light load 对应为性能测试，Heavy Load 对应为负载测试，Buckle Zone 对应为压力测试……还有很多的对应关系。
事实上，这是不合理的。
下面我将用场景的定义来替换这些混乱的概念。
为什么我要如此划分？因为在具体场景的操作层面，只有场景中的配置才是具体可操作的。而通常大家认为的性能测试、负载测试、压力测试在操作的层面，只有压力工具中线程数的区别，其他的都在资源分析的层面，而分析在很多人的眼中，都不算测试。
拿配置测试和递增测试举例吧。
在性能中，我们有非常多的配置，像 JVM 参数、OS 参数、DB 参数、网络参数、容器参数等等。如果我们把测试这些配置参数，称为“配置测试”，我觉得未免过于狭隘了。因为对于配置参数来说，这只是做一个简单的变更，而性能场景其实没有任何变化呀。配置更改前后，会用同样的性能场景来判断效果，最多再增加一些前端的压力，实际的场景并没有任何变化，所以，我觉得它不配做为一个单独的分类。
再比如递增测试，在性能中，基准性能场景也好，容量性能场景也好，哪个是不需要递增的呢？我知道现在市场上经常有测试工程师，直接就上了几百几千线程做压力（请你不要告诉我这是个正常的场景，鉴于我的精神有限，承受不了这样的压力）。除了秒杀场景，同时上所有线程的场景，我还没有见到过。在一般的性能场景中，递增都是必不可少的过程。同时，递增的过程，也要是连续的，而不是 100 线程、200 线程、300 线程这样断开执行场景，这样是不合理的。关于这一点，我们将在很多地方着重强调。所以我觉得递增也不配做一个单独的分类。
其他的概念，就不一一批驳了。其实在性能测试中，在实际的项目实施中，我们并不需要这么多概念，这些杂七杂八的概念也并没有对性能测试领域的发展起到什么推进作用。要说云计算、AI、大数据这些概念，它们本身在引导着一个方向。
而性能测试中被定为“测试”，本身就处在软件生存周期的弱势环节，当前的市场发展也并不好。还被这些概念冲乱了本来应该有的逻辑的思路，实在是得不偿失。
总结
总之，在具体的性能项目中，性能场景是一个非常核心的概念。因为它会包括压力发起策略、业务模型、监控模型、性能数据（性能中的数据，我一直都不把它称之为模型，因为在数据层面，测试并没有做过什么抽象的动作，只是使用）、软硬件环境、分析模型等。
有了清晰的、有逻辑的场景概念之后，在后面的篇幅当中，我们将从场景的各个角度去拆解。在本专栏中，我们将保持理念的连贯性，以示我不变的职业初心。
思考题
如果你理解了今天的内容，不妨说说为什么说现在市场上的概念对性能项目的实施并没有太大的价值？其次，性能场景为什么要连续？而不是断开？
欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享赞 39
提建议
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
01丨性能综述：性能测试的概念到底是什么？
下一篇
03丨性能综述：怎么理解TPS、QPS、RT、吞吐量这些性能指标？
精选留言(84)
zuozewei2019-12-17第一个问题： 日常生活中价值可以通俗的理解为“合算不合算”，“值得不值得”，这里泛指对性能项目的有益程度。 在价值工程中，价值是个科学的概念，其定义为：V=F/C 式中： V——价值（Value） F——功能评价值（Function Worthy） C——总成本（Total Cost） 可见，包括三个基本要素，即价值、功能和成本。 功能可解释为用途、目的等等。对于一个性能项目来说，功能就是性能验证 or 性能分析 or 性能调优。 概念这里简单理解为“思维惯性”，其会决定做一个性能项目的行为模式，是指实现功能（性能验证 or 性能分析 or 性能调优）所支付费用（成本）。 SO，为了提升价值，在功能（目的）不变的情况下唯有适当的降低不合适的成本，那么这些杂七杂八，逻辑关系不符合真实的场景的概念势必需要淘汰。 第二个问题： 性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。 那么如何看性能数据呢？ 一般有两个核心即趋势和证据链。 分析数据趋势需要对一个时间序列数据的分析，一般采用线性回归分析。 对于证据链查找，需要对不同时间序列数据的分析，一般采用数据的相关性分析。展开作者回复: 你写的比我写的还要好。哈哈。下面的篇幅中就要有趋势和证据链的部分。这也是我觉得性能中最重要的部分。我混了混迹江湖十几年的依靠。
共 5 条评论97
莫西 👫 小妞儿 ...2019-12-30老师，我有个疑问。“单交易容量测试”是对单独接口进行压测是吧？比如针对每一个接口都测了100、200、300并发。那么这个测试结果和“混合容量性能场景”测完的结果应该怎么对比分析呢？作者回复: 不用对比分析。 做单交易容量测试是为了混合容量做基准数据的。举例来说。 业务1单交易容量能达到300TPS，且响应时间也非常好。而在混合中，可能业务1只需要100TPS，那就说明业务1不会成为混合容量的瓶颈点。 如果业务1单交易容量的时候只能达到50，而在混合场景中需要它能跑到100，怎么办？这就只能在单交易的时候做优化了。 所以单交易容量测试是为了确定是不是应该在单交易容量阶段做性能优化。 题外话：要注意的是混合容量中有相互的逻辑关系，这个必须到混合容量的时候才会出现。
共 5 条评论43
suke2020-03-08但是由于用户数增加的幅度会超过队列长度，所以 TPS 仍然会增加 这句话没明白这个逻辑是为什么？能详细解释一下么作者回复: tps之所以会增加是因为线程数的增加，而tps之所以增加的缓慢，是因为性能已经衰减。性能衰减必然产生请求队列。如果所有增加的请求都被放在了队列中，那处理的请求数就不会增加，响应也不会增加，tps就不变了。
共 8 条评论36
丑得带感2019-12-23有个问题想请教一下老师： 关于TPS与并发线程数，正常应该是以TPS作为系统容量的衡量标准，这个在系统性能比较好的时候很好和客户沟通（即TPS>并发数）。 但是在系统性能较低的项目中，有时候就很难和客户沟通，比如一次项目中，系统在2000并发，系统TPS就到了最大1500多，RT、资源利用率那些也还好；但是接着增加并发到5000时，TPS基本比较平稳，没有什么下降，响应时间才刚刚超时。 对于这种情况，在估算系统可支撑最大在线人数时，客户就觉得应该依据最大并发数5000去算（RT可接受时），而不是依据最大系统TPS1500多去算，他们觉得你的每1个并发都是模拟的1个用户在实际使用，而响应时间没超时，就说明可以支撑这个并发数的用户同时使用（假设并发度100%时）。 我从响应时间分析，感觉他们的说法也没毛病，但是理智告诉我，从TPS看系统每秒最大也就能处理1500多，其余的请求应该会在队列超时，或被拒绝，但是5000并发持续压测10分钟，也没看到大量超时或报错（千分之一以下），拿不出证据来支撑，感觉真是性能三观都要被颠覆，一直耿耿于怀，还请老师解惑！展开作者回复: 在你的描述中，响应时间也还好，是什么程度的还好？如果从2000到5000，TPS平移，那响应时间至少上升了2.5倍。 即使这时还没到响应时间超时，也只能说明超时时间比较长，请求都放在队列中去了。对终端用户来说，就是感觉上的系统卡死。 如果这时你再上线程，是不是超时就会增加了？ 其实就是：压力机线程、TPS、RT之间的转换关系。 从系统用户的角度来看，系统性能是在不断下降的。而不是技术上来看，没有超时和报错就是性能还可以支撑。
共 3 条评论26
jy2020-05-24递增策略：比如分钟增加10个线程，100个线程要10分钟才全部启动完成，再持续运行10分钟，但是聚合报告统计的是这20分钟的tps，tps值明显会被前面10分钟拉低，如果这样测试出来的tps不达标怎么办？如果每分钟启动50个，2分钟即可全部启动，持续运行10分钟，tps达标。如何解释这两种情况呢？作者回复: 所以判断最大TPS的时候，不是用聚合报告中的那个平均TPS值。而是看整个TPS曲线的最大TPS值。。
共 3 条评论18
微冷花谢2019-12-18请老师允许我一个新手留下自己的思考和疑问? 第一问，自己的思考是很多理论上的概念，不仅仅加深了我们对性能测试的理解的困难程度。同时，在实际发现性能瓶颈，实施性能优化，很多时候是没有太多帮助的。 第二问，之所以需要连续的一个符合实际的加压过程，是因为能够获取更加完整且准确的证据链。 个人疑问:关于如何去设计递增加压的过程，根据什么去设计，如何去设计出符合我们系统的加压过程? 对于老师的两问，个人理解不一定正确，希望老师指正。 对于个人疑问，麻烦老师留下思路。 最后，老师的讲的真实在，谢谢老师的分享。虽然有一些我还没办法懂，但是我会极力的去吸收。谢谢老师！展开作者回复: 第一问：理解的很对。理论来自于实践，并且要再应用到实践中去。 才是真正的有价值。 第二问：前半句说的对，就是要一个符合实际的加压过程。后面句方向有点偏，连续不是为了获取证据链，而是为了判断瓶颈点的出现和性能衰减的过程，分析这个过程产生的压力数据、监控数据得到瓶颈点的过程才是获取证据链的。 针对个人疑问：后面的场景中，会更详细的提到。 在这里简单说一下，递增加压的过程是为了让一个系统的性能衰减过程可以清晰判断出来。而递增的量级就完全取决于业务系统的能力了。如果业务处理的响应时间长，在系统瓶颈还未明显出现时就递增的快一些；反之就慢一些。后续篇幅中再细看吧。
共 2 条评论9
IT媚娘2019-12-17性能场景为什么要连续？而不是断开？ 递增线程数，记录每次的性能指标，对比分析，画曲线，来观察指标变化的趋势，找出性能瓶颈，或者服务器最大处理能力作者回复: 理解的非常正确。
共 2 条评论7
LensAclrtn2019-12-171. 为什么说市场上的概念对性能项目实施没有太大价值? 看完第1、2讲,感觉老师真的是很真诚很负责,说出了很多我们想说不敢说的话 就拿老师举例的配置测试来说,我当时陆陆续续接触到这么些概念的时候就在想,这都谁造出来的词,连配置这么个基本操作也要上升到XX测试的程度...最搞笑的是还有一种叫“文档测试”的.感觉这些都太重理论轻实践了. 说个题外话,我以前虽然也对性能测试、压力测试、负载测试颇有微词,但自己也不能总结提炼出一个更好的分类框架或者体系, 今天看到老师用性能场景来作为划分依据,就是重实践的表现,很值得我们学习呢. 2. 为什么性能场景要连续不要断开? 说来惭愧,我第一个负责压测的时候就是用的离散的性能场景,也就是一次测试过程中线程数是固定的. 现实中的性能场景都不是一成不变的, 用固定的线程数去压测的意义很有限展开作者回复: 能有这样的评论，我觉得很欣慰，有认同感。 我深受概念扰乱多年，总是得跟人解释一顿我认为对的概念和操作方式。
共 6 条评论5
分清云淡2019-12-16QPS=并发数*常数/RT , 也就是到瓶颈后加并发后RT增加QPS不变，那么瓶颈基本在RT增加的节点上。作者回复: 你理解的很对。 对性能来说，性能瓶颈肯定是在RT增加的节点的。
共 6 条评论5
-_-2020-08-04TPS 和QPS是一个东西么 我看概念是不一样的 但是有的用QPS 有的用TPS 这两个东西怎么个区别作者回复: 这个就看自己想如何定义，我提到的T都是指事务，而事务是个灵活的概念，在每个项目中都可以自己去确定事务的大小。 而QPS....，说实话，我也不用。
4
拥抱黑夜的白天2020-05-301、市场上很多概念都是人云亦云，没有实际的应用到项目中去，而是以偏概全，甚至理解上存在误差、片面化，但是却被广泛的传播开造成了误导。而且没有通过实践证明的概念是没有实际的意义的。我认为真正的概念不是片面的、也不是单纯的理论性的，应该是从实际的业务中总结得出的结论，才会对实际的有指导意义。而我们也需要从项目中探索和积累经验、教训，不断丰富和完善我们的理论体系。总之一句话，实践出真知，任何没有实践做支撑的理论都是假想！ 2、因为在实际的业务场景中，基本上不太会出现一下子增长很多用户量的情况，除非是限时秒杀这种业务场景，一般都是数据一点点增长上来的。我们做性能测试，要模拟还原真实的业务场景才有实际的意义和价值。展开作者回复: 说的非常对。
共 2 条评论4
chary2019-12-30做了这么多年的性能测试，容量测试找拐点一致都是我头疼的，每次都是经过很多次反反复复的加压，梯度压测，最终找到拐点。经常会有无用功的时候，不知道高老师是不是也一样！有没有什么好的方法！谢谢作者回复: 哈哈，在我的理念中，就不用管拐点不拐点的事。 因为TPS在大部分场景中都是是缓慢上升的，是一个有明显弧度但没有明确拐点的曲线。 所以你要是问我方法，我会告诉你放弃这个拐点更为简单。
4
Cyx2020-12-11老师，这段话没有懂，没有明白为什么TPS仍然会增加——很多时候，重负载区的资源饱和，和 TPS 达到最大值之间都不是在同样的并发用户数之下的。比如说，当 CPU 资源使用率达到 100% 之后，随着压力的增加，队列慢慢变长，但是由于用户数增加的幅度会超过队列长度，所以 TPS 仍然会增加，也就是说资源使用率达到饱和之后还有一段时间 TPS 才会达到上限。作者回复: 根据响应时间的增加幅度计算就可以知道。假设响应时间增加了50%，线程数增加了100%，那tps就还会增加。
3
人心向善2020-07-21做了几年的测试都是比较传统，客户要求也比较明确，都是为了验收或者拿到一个简单的成果就行，他们的要求就是时间上不要超时，而且能达到我要求的并发数就行了，根本不会去考虑什么tps吞吐量这些东西，这样带来的坏处就是即使在实践中也很难达到能力的提升，时间长了就会进到一个错误的误区，就只是认为性能测试只看这几项要求，实则不是这样 还有就是做性能测试总体来说要求会的太多了，因为你不像开发精通一门语言就可以持续的做整个业务，性能测试这块完全取决于你的被测系统是什么架构由哪些新技术构成的，这个时候就会陷入另一种困境就是这个技术第一次接触，无论是从哪个角度对实施人员都是一头雾水，很难快速的进入到测试状态，即使是你的测试模型准备好了，测试出来的结果也不知道怎么去分析，如何分析... 简单的从网络、硬件、web应用这些、复杂点的到网络协议、磁盘利用、数据库参数、底层代码逻辑等等，这些都要一点点去分析比对的，但是这些东西一时间又不能全部去完全的理解并且能够上手，所以其实更多的时候是陷入了一种特别无奈的迷茫，但俗话又说：实践是检验真理的唯一标准，你只有去实践了才知道哪里对了哪里错了，经历了一定实践搞明白一些事情，觉得自己会了很多，可客户不这么想，他就觉得你技术不行，因为他要的很明确：结果就是结果，毕竟时间成本都在这里。 从这方面来说不仅技术上有问题，项目管理上也就出了问题了，因为已经不符合管理的三要素了....展开作者回复: 看来是经历了很多失败的性能项目呀。
3
瑞泉2020-02-22老师，我是测试的新人，在第一个图中没有看到两个点：最优并发用户数（The Optimum Number of Concurrent Users）、最大并发用户数（The Maximum Number of Concurrent Users）的标注，在第二张图中也没有，希望老师能标注一下，十分感谢！作者回复: 上面有两条竖线。第一个是最优并发用户数（The Optimum Number of Concurrent Users），第二个是最大并发用户数（The Maximum Number of Concurrent Users）。
共 3 条评论3
luxuluck2022-03-28你好老师 请问你所给的TPS和响应时间曲线中的A、B、C、D、E 分别代表什么 ；A和B有什么区别啊作者回复: A是响应时间开始上升的点；B是业务可接受的响应时间点；C是容量峰值点；D没有特别含义；E是系统崩溃点。
2- Technological life2020-04-24jmeter里的线程数是不是就是用户数呢？线程数和用户数的关系是什么呢？
作者回复: 在我的理念中，一个T的设定为业务含义时，T才是用户。线程是实现T的。
共 2 条评论2 
Geek_a5ffcf2022-04-01老师，其实tps和响应时间的关系就是tps=压力线程数/响应时间，对吧作者回复: 你这句话有一个前提就是一个压力线程只有一个T。
共 2 条评论1
Cathy2022-01-09看了标题，有些紧张，有点不敢点开，担心归纳出什么数学公式出来，烧脑。 为了赶进度，不得不继续。还好，这一讲，继续探讨概念。上一讲从性能测试过程来讲，这一讲从性能场景的角度来讲。听了3遍，静下心来，终于听懂了。作者回复: 有公式也是有小学基础就能懂的，别怕。哈。
1
Geek_6bb2021-09-05老师你好！我想问下 1.基准测试里面提到的最大tps是指在响应时间指标内的tps，还是不看响应时间下的最大tps 2.比如我的A业务有一个接口，B业务有2个接口，C业务有5个接口 做混合场景的时候需要给B，C业务分别加一个事物控制器吗作者回复: 1，当然要看响应时间。 2，我理解是要加的。
1
