性能测试实战30讲」之问题问答整理三

03丨性能综述：怎么理解TPS、QPS、RT、吞吐量这些性能指标？

思

考

你能思考一下，为什么 258 响应时间不合理吗？像“业务模型用 28 原则”这些看似常识性的知识点，错在哪里呢？

老师好，有个问题麻烦问下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，要是发多了，后面停的时间就长。

1. 第一个问题： 这个命题的争论有个bug，问题在于「快、好」的定义上。做为不同业务下的性能水平，快的定义是不一样的，比如在数据处理业务中，常分OLAP（联机分析处理）、OLTP（联机事务处理），比如一个简单的 OLTP 查询有大厂是要求微妙级别的，OLAP 统计报表类的业务查询几分钟也是可以接受啊。
2. 第二个问题： 在一个具体的业务场景中，性能场景中的业务模型和二八原则并没有什么关系，即使从宏观上来说有关系，也是很牵强的，至少至今为止，还没看到任何有数据和数学公式的支撑证明。

作者回复: 深得真传。哈哈。

1. 第一个问题： 不合理之处在于没有结合实际场景去规定它的响应时间。响应时间是否合理是要进行对比的，例如现在的大数据技术测试，在不同的条件配置下处理TB级的数据，响应时间半天、一天都可以说是合理的响应时间。因为影响响应时间的因素有很多（存储方式，调度方式，参数调优等），单独拿“258”说明是没有意义的。
2. 第二个问题： 常识的适用情况在于通用，但实际场景中经常会有各种“意外”。以12306购票系统为例，以前春运抢票时经常会有朋友、家人吐槽12306好卡、好慢，我估计之前就是业务模型用了28原则，虽然已经进行过了压力测试、疲劳测试，但还是抵挡不住全国人民着急回家的心情，拼命的发送请求......所以实际情况要实际考虑，以通用估意外肯定会才很多坑，只有不断地优化，更新才能一步步满足用户地需要。（PS：现在12306系统已经好很多了）

作者回复: 理解的非常正确。

如果这时响应时间是 100ms，那显然并发线程数是 500TPS/(1000ms/100ms)=50(并发线程)。这没看明白是什么意思

作者回复: 对一个线程来说，如果响应时间是100ms，那这个线程在一秒内不就是：1000ms/100ms = 10tps了吗？ 如果要达到500TPS，那需要多少线程呢？就是500TPS/10TPS=50线程。

第一个问题，世界上没有一个放之四海而皆准的原则理论，拿来就用必出问题，唯有知其然，知其所依然，才能正确使用。感谢老师给我们上了生动的一课，在学习中始终保持一份好奇心，多思考，多问几个问题，才能学以致用。

第二个问题，二八定律是19世纪末20世纪初意大利经济学家帕累托发现的。帕累托从大量具体的事实中发现：社会上20%的人占有80%的社会财富，即：财富在人口中的分配是不平衡的。现在这个定律被广泛用在很多领域，比较有名如时间管理认为，20%的时间完成80%的工作。其实我个人认为，就时间管理而言，这个二八定律也是不合适的，是学渣们自我偷懒的借口。所以很喜欢老师说的，不要满口理论、定律等花架子，应该按照业务，按照样本数据分析结果，从实际出发，这样才能实事求是，做出符合实际的业务预估。 这堂课还需好好消化，也建议老师结合自己的实践，提出你自己的模型，让我们学习参考借鉴！

作者回复: 理解的非常正确。希望后续的篇幅能让你满意。我也尽我所能。

老师，我有些点不太确定： 1.在线用户数是通过监控得出的数据吗？ 2.并发度是主要业务才会大些，其他业务的并发度在1%～5%？ 3.TPS是有上面两个业务指标计算得出来的？ 4.响应时间是通过生产数据得出的，算是已知条件？ 5.并发线程是由TPS *响应时间得出的，是需要计算的？

作者回复: 1. 通过监控可以得出。 2. 在我的经验中，其实主要业务才有1%~5%。 345. TPS、RT和压力机的并发线程数。都是不用计算的，是直接通过测试执行得出的。在文中所说的只是说明他们之间的关系而已。

响应时间的258原则和业务模型的28原则，我在网上也看到过。听了老师的讲解，我觉得这样的原则其实是有年代或者一定的背景限制的，正如那个响应时间的258，说的是那个年代的音乐缓冲服务， 特定的年代，特定的系统，虽然经典，但很局限，它不能代表所有的系统，更何况随着科技发展和人们对时间和速度的要求，这样的原则显然不太符合。真正需要了解某个系统响应时间的需求，还真是靠同行业系统的参照或者对样本群体的统计分析更靠谱！

作者回复: 能有赞同感很欣慰。

并发线程数是500TPS/(1000ms/100ms)=50(并发线程)。这里的1000ms怎么来的？不懂这个计算方式

作者回复: TPS中的S就是1秒，1秒是1000毫秒。1000ms就是这样来的。。

258原则应该是指，用户打开页面到看到页面数据的时间，性能测试的场景有很多种，不一定适用所有

作者回复: 现在应该算是完全不适用了。