03丨性能综述：怎么理解TPS、QPS、RT、吞吐量这些性能指标？
该思维导图由 AI 生成，仅供参考
对这些性能指标都有哪些误解
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了性能测试中常用的性能指标，如TPS、QPS、RT、吞吐量等，并强调了这些指标需要与业务指标相结合，不能脱离业务场景单独考虑。文章指出了性能测试工程师需要进行时间拆分定位，而不仅仅是报告压力工具中看到的响应时间。此外，文章还解释了压力工具中的线程数和用户数与TPS之间的关系，以及业务模型的28原则的合理性。作者还对性能指标的计算方式进行了深入分析，指出了一些公式的问题和假设条件的不合理性。最后，文章总结了性能测试的关键概念，包括性能指标、性能模型、性能场景、性能监控、性能实施和性能报告，并提出了一些思考题，引发读者对性能测试的深入思考。整体而言，本文通过举例和详细解释，帮助读者重新理解了性能指标的概念和使用方法，为性能测试领域的从业者提供了有益的参考和思考。
《性能测试实战 30 讲》，新⼈⾸单¥59
全部留言(137)
- 最新
- 精选
- 飞翔如果这时响应时间是 100ms，那显然并发线程数是 500TPS/(1000ms/100ms)=50(并发线程)。 这没看明白是什么意思
作者回复: 对一个线程来说，如果响应时间是100ms，那这个线程在一秒内不就是：1000ms/100ms = 10tps了吗？ 如果要达到500TPS，那需要多少线程呢？就是500TPS/10TPS=50线程。
2019-12-181294 
nana老师好，有个问题麻烦问下jmeter压测constant throughput timer中设置的qps ，实际中的threads是怎么分配的？对于number of threads（users）和ramp-up period设置压上去的throughput和前面提到的qps这个不同点，麻烦解释下，辛苦多谢啦作者回复: 这里我把constant throughput timer设置为all threads来说。 1. 如果constant throughput timer里设置了10 samplers per min，即是不管你有多少threads，都是只发10个samplers per min出去。 如果你设置了1个thread，那就是6秒发一个。 如果你设置了2个threads，那就是一次发2个，12秒发一次。 如果你设置了20个threads，那就是一开始就会发20个出去，然后再等2分钟之后再发后面20个。 number of threads（users）和ramp-up period不管如何设置，都会受前面设置的constant throughput timer控制。即是按分钟来计算sampler，要是发多了，后面停的时间就长。
2019-12-19422
zuozewei第一个问题： 这个命题的争论有个bug，问题在于「快、好」的定义上。做为不同业务下的性能水平，快的定义是不一样的，比如在数据处理业务中，常分OLAP（联机分析处理）、OLTP（联机事务处理），比如一个简单的 OLTP 查询有大厂是要求微妙级别的，OLAP 统计报表类的业务查询几分钟也是可以接受啊。 第二个问题： 在一个具体的业务场景中，性能场景中的业务模型和二八原则并没有什么关系，即使从宏观上来说有关系，也是很牵强的，至少至今为止，还没看到任何有数据和数学公式的支撑证明。作者回复: 深得真传。哈哈。
2019-12-1718
顺利同学提问： 那是不是jmeter测试每秒500个用户并发 就是设置50个线程 Ramp-Up为1秒？老师的回复: 不一定，要看响应时间是多长，做出有梯度的场景来。 我的问题是：如果响应时间是10ms，如何得出这个梯度的场景。求解答作者回复: 没理解这个问题是啥。 首先要测试每秒500用户并发，那就要看你设置事务的粒度了。要计算并发的线程应该有多少，才能支持500用户并发，也就是前文提到的并发度。 响应时间是10ms，梯度场景要根据系统能够支持的最大TPS来计算，这个最大TPS可以通过二分法来评估。当响应时间是10ms时，显然一个压力线程会产生100TPS，如果系统大概能支持2000TPS，在不考虑性能损耗的情况下，就是需要20个压力线程，一般在这种情况下，我会做4-5个梯度。
2020-02-17614
律飛第一个问题，世界上没有一个放之四海而皆准的原则理论，拿来就用必出问题，唯有知其然，知其所依然，才能正确使用。感谢老师给我们上了生动的一课，在学习中始终保持一份好奇心，多思考，多问几个问题，才能学以致用。 第二个问题，二八定律是19世纪末20世纪初意大利经济学家帕累托发现的。帕累托从大量具体的事实中发现：社会上20%的人占有80%的社会财富，即：财富在人口中的分配是不平衡的。现在这个定律被广泛用在很多领域，比较有名如时间管理认为，20%的时间完成80%的工作。其实我个人认为，就时间管理而言，这个二八定律也是不合适的，是学渣们自我偷懒的借口。所以很喜欢老师说的，不要满口理论、定律等花架子，应该按照业务，按照样本数据分析结果，从实际出发，这样才能实事求是，做出符合实际的业务预估。 这堂课还需好好消化，也建议老师结合自己的实践，提出你自己的模型，让我们学习参考借鉴！作者回复: 理解的非常正确。希望后续的篇幅能让你满意。我也尽我所能。
2019-12-209
miminiMei老师的声音好好听，可以一直听，反复听😉作者回复: 多谢鼓励。不过还是要关注技术重点哦。哈。
2019-12-199
秋水共长天一色🌄老师你好，我在读了你的这篇文章之后也产生了几个疑问。 1.就在文中你在解释TPS中的T的定义时，你提到了三种脚本情况，1是接口级，2是业务级，3是用户级。主要用户级中有提到一个点击的动作的这个步骤，如果在jmeter中进行压测是要怎样体现这个步骤？还有我们定义业务接口层脚本时是只将主流程的接口收录呢还是说会将这个页面下所有的接口都收录呢？（例如在一些商城项目中，确认订单页面有生成订单的接口，这个我们可以认为这是主流程的接口，但是也有可能有调一些关于获取广告信息的接口，但是这个接口与主流程下单流程没什么关系，但是又确实消耗了服务器资源了，那我们在写脚本时是否还需要把这部分也写进去） 2.一个事务的完成我理解的是主要看这个脚本是如何编写的，如果这个事务的脚本中只有针对一个接口而已，那么接口请求完成后就算是完成一个事务。如果这个事务脚本中有10个接口组成的事务，那就需要10个接口都请求完成了才算一个事务的完成，这样理解对吗？ 3.对于QPS，我们在实际工作中我们要如何得知数据库查询在整个请求中所占的比重呢？ 4.在解释RPS的时候给出了一个例子（如果一个用户点击了一次，发出来 3 个 HTTP Request，调用了 2 次订单服务，调用了 2 次库存服务，调用了 1 次积分服务），这三个http请求我能理解，但是中间你是用了“调用”这个词，这里的调用是指订单服务内部去调用库存服务和积分服务的外放接口还是说调用的库存服务和积分服务公开的方法？ 5.还有在并发线程时有提到一个公式（500TPS/(1000ms/100ms)=50(并发线程)），我想知道其中的这个100ms的这个响应时间是如何得出的？是通过对一个脚本进行单一线程执行一次的方式得出的响应时间吗？ 6.还有这个课程解答了很大一部分我对与性能测试中想不通的点，这个课程很值，感谢老师的分享。作者回复: 1. 用户级会包括业务下的所有接口。 2. 理解的对。 3. 看时间长度。 4. 不管是调接口还是调方法，不都是调用 吗？ 5. 基准测试场景的结果。
2020-05-308
夜空中最亮的星这一篇超值了作者回复: 有过性能经验的人都会有超值的感觉。哈哈。
2019-12-178
妍老师您好，有个问题请教一下 ，在jmeter中，设置200 并发，1s内发出，，执行结果中 平均响应时间为6ms，，那我的TPS 计算是200还是200*（1/0.006）呢？作者回复: 当然是后者。
2020-04-0257- 大脸猫老师，请问吞吐量怎么理解我一直没明白，吞吐量和TPS，响应时间之间有什么关系
作者回复: 通常我都不用吞吐量这个概念。因为它在不同人的脑子里会存在一些误解。 比如说，有些人说吞吐量就是在说TPS。有些人说吞吐量是说的每秒字节数。 所以不建议用这个概念来承载性能指标。有TPS就够了。
2020-01-137
