[性能测试实战30讲」之问题问答整理十一

思考题：

思考题

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

读者A：

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

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

读者B：

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

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

读者C：

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

读者D：

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

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

读者E：

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

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

读者F：

同学提问：那是不是jmeter测试每秒500个用户并发 就是设置50个线程 Ramp-Up为1秒？老师的回复: 不一定，要看响应时间是多长，做出有梯度的场景来。 我的问题是：如果响应时间是10ms，如何得出这个梯度的场景。求解答

作者回复: 没理解这个问题是啥。 首先要测试每秒500用户并发，那就要看你设置事务的粒度了。要计算并发的线程应该有多少，才能支持500用户并发，也就是前文提到的并发度。 响应时间是10ms，梯度场景要根据系统能够支持的最大TPS来计算，这个最大TPS可以通过二分法来评估。当响应时间是10ms时，显然一个压力线程会产生100TPS，如果系统大概能支持2000TPS，在不考虑性能损耗的情况下，就是需要20个压力线程，一般在这种情况下，我会做4-5个梯度。

读者G：

你能思考一下，为什么 258 响应时间不合理吗？像“业务模型用 28 原则”这些看似常识性的知识点，错在哪里呢？ （1）258我感觉更像是一个约定俗成的东西，比如人们常说的前端响应要<3s，只是一个常识标准没有任何决定性意义。258也同样可以是269，147 （2）28原则类似业务模型了吧，注意业务模型概念而不应该注意28这个比率，每个系统的业务模型都不相同。第一次听楼哥的并发率概念感觉这个更好用

作者回复: 理解的不错哦。多谢支持。

读者H：

1. 258原则不合理的地方在于没有结合实际业务场景。该258原则也只是80年代某公司做的调查，在当时用户可以接受。对于21世纪的今天他的指导作用并不大。 2. 业务模型的28原则，错在脱离业务本身。每个系统的并发度都由业务来确定。

作者回复: 说的很对。

读者I：

QPS 和 TPS 到底是什么关系呢？

作者回复: T是一个灵活的定义。取决于你把它设置的范围有多大。 QPS是一个我只在数据库中用的概念，所以我不觉得它和T有什么可直接关联的关联。 除非在一个特定的应用中，已经确定了一个T的范围，可以获取到这个T会产生多少个Q，如此而已。

读者G：

请问下时间拆分这块怎么做，比如链路是（忽略硬件设备）jmeter-nginx-tomcat-mysql，比如jmeter-nginx中间，请求和返回的时间怎么计算？nginx到tomcat之间的耗时怎么计算，tomcat-mysql之间的耗时如何计算？而自身nginx，tomcat，mysql处理逻辑或者业务的时间耗时又如何计算呢？

作者回复: 这个我在专栏中有说明吧。 像nginx上就有request time和response time时间。tomcat也有。 mysql的处理逻辑或业务的时间耗时这句没看懂是什么意思？对SQL要看的是从执行到结束的每个环节。

读者K：

老师，请问吞吐量怎么理解我一直没明白，吞吐量和TPS，响应时间之间有什么关系;

有个问题面试官问了我 但是我忘记问答案了 并发数不高的情况下 数据库和应用服务器资源维持在70%左右 吞吐量一直在增加 但是TPS在下降 这个什么原因造成的

作者回复: 通常我都不用吞吐量这个概念。因为它在不同人的脑子里会存在一些误解。 比如说，有些人说吞吐量就是在说TPS。有些人说吞吐量是说的每秒字节数。 所以不建议用这个概念来承载性能指标。有TPS就够了。

作者回复: 这个问题需要详细的场景数据。你这样的描述没判断做分析判断哦。

读者L：

首先2/8原则的业务模型划分就极为牵强，我认为IT行业业务变来变去玩的就是数据，没有数据来证明就下结论就跟耍流氓没啥区别，就相当与领导给你打绩效，没有说明你这个月有什么失误，认为给你一个表现不好的同事扣了绩效，也就给你扣了绩效，你难道就忍了？应该结合生产数据去做评估。 然后是2/5/8的响应时间，唉、都0202年了···不同行业，不同业务，不同场景~应该分别去对待吧。

作者回复: 说的很对。我也这样认为。