2019-12-18如果这时响应时间是 100ms，那显然并发线程数是 500TPS/(1000ms/100ms)=50(并发线程)。 这没看明白是什么意思作者回复: 对一个线程来说，如果响应时间是100ms，那这个线程在一秒内不就是：1000ms/100ms = 10tps了吗？
如果要达到500TPS，那需要多少线程呢？就是500TPS/10TPS=50线程。 2 9
2019-12-17第一个问题：
这个命题的争论有个bug，问题在于「快、好」的定义上。做为不同业务下的性能水平，快的定义是不一样的，比如在数据处理业务中，常分OLAP（联机分析处理）、OLTP（联机事务处理），比如一个简单的 OLTP 查询有大厂是要求微妙级别的，OLAP 统计报表类的业务查询几分钟也是可以接受啊。
第二个问题：
在一个具体的业务场景中，性能场景中的业务模型和二八原则并没有什么关系，即使从宏观上来说有关系，也是很牵强的，至少至今为止，还没看到任何有数据和数学公式的支撑证明。展开作者回复: 深得真传。哈哈。
8
2019-12-19老师好，有个问题麻烦问下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，要是发多了，后面停的时间就长。 2 5
2019-12-17有没有一套相对普适的测试场景、衡量指标以及对应的测试方法论？看完3篇感觉思维有点儿混乱。也可能是自身想通过课程走捷径，有点急躁，谢谢🙏作者回复: 别急，后面的更新中就有你想要的测试场景的具体推演方法。
4- 2019-12-19第一个问题：
不合理之处在于没有结合实际场景去规定它的响应时间。响应时间是否合理是要进行对比的，例如现在的大数据技术测试，在不同的条件配置下处理TB级的数据，响应时间半天、一天都可以说是合理的响应时间。因为影响响应时间的因素有很多（存储方式，调度方式，参数调优等），单独拿“258”说明是没有意义的。
第二个问题：
常识的适用情况在于通用，但实际场景中经常会有各种“意外”。以12306购票系统为例，以前春运抢票时经常会有朋友、家人吐槽12306好卡、好慢，我估计之前就是业务模型用了28原则，虽然已经进行过了压力测试、疲劳测试，但还是抵挡不住全国人民着急回家的心情，拼命的发送请求......所以实际情况要实际考虑，以通用估意外肯定会才很多坑，只有不断地优化，更新才能一步步满足用户地需要。（PS：现在12306系统已经好很多了）展开作者回复: 理解的非常正确。
2 
2019-12-17一模一样，每个人都认为不是自己的问题作者回复: 所以就得有仲裁能力的人，而这个人就应该是性能测试团队中来，在我的工作经历中，我的团队就是干这个仲裁的事情。
2
2019-12-16其实我觉得这个什么所谓的28，258，25810原则都是虚的，直接点就是测目前系统实际的并发数和吞吐量作者回复: 非常正的想法。响应时间从来都没有标准。
1 2
2020-01-06可以讲讲其他性能指标么？比如常用数据库的、常用中间件的（Weblogic、kafka。。）等作者回复: 后面写。
1
2019-12-23赞一个，对于刚做性能的我，这文章很好的查漏补缺。258原则那里之前一直被其他人误导，其实自己做的时候都觉得有点奇怪怎么还会按照258原则来做标准呢，现在这年代3秒都觉得慢了。。作者回复: 以讹传讹的理念根深蒂固。而战斗在一线的都深受其苦。
1
2019-12-20第一个问题，世界上没有一个放之四海而皆准的原则理论，拿来就用必出问题，唯有知其然，知其所依然，才能正确使用。感谢老师给我们上了生动的一课，在学习中始终保持一份好奇心，多思考，多问几个问题，才能学以致用。
第二个问题，二八定律是19世纪末20世纪初意大利经济学家帕累托发现的。帕累托从大量具体的事实中发现：社会上20%的人占有80%的社会财富，即：财富在人口中的分配是不平衡的。现在这个定律被广泛用在很多领域，比较有名如时间管理认为，20%的时间完成80%的工作。其实我个人认为，就时间管理而言，这个二八定律也是不合适的，是学渣们自我偷懒的借口。所以很喜欢老师说的，不要满口理论、定律等花架子，应该按照业务，按照样本数据分析结果，从实际出发，这样才能实事求是，做出符合实际的业务预估。
这堂课还需好好消化，也建议老师结合自己的实践，提出你自己的模型，让我们学习参考借鉴！展开作者回复: 理解的非常正确。希望后续的篇幅能让你满意。我也尽我所能。
1
2019-12-19老师的声音好好听，可以一直听，反复听😉作者回复: 多谢鼓励。不过还是要关注技术重点哦。哈。
1
2019-12-17这一篇超值了作者回复: 有过性能经验的人都会有超值的感觉。哈哈。
1- 2019-12-17有点虚，都是讲一些 指标计算方式 不准，能否给一个准的？ 新的刚开发的系统什么都没有，怎么收集线上业务数据？
作者回复: 新开发的产品当然不是收集线上业务数据的方式。而应该来自于产品设计的团队，或同行业的数据比对。
1 1 
2019-12-16一口气看完三篇，很契合工作中的性能测试作者回复: 多谢支持。多交流。
1
2020-02-08QPS 和 TPS 到底是什么关系呢？作者回复: T是一个灵活的定义。取决于你把它设置的范围有多大。
QPS是一个我只在数据库中用的概念，所以我不觉得它和T有什么可直接关联的关联。
除非在一个特定的应用中，已经确定了一个T的范围，可以获取到这个T会产生多少个Q，如此而已。
2020-01-19请问下时间拆分这块怎么做，比如链路是（忽略硬件设备）jmeter-nginx-tomcat-mysql，比如jmeter-nginx中间，请求和返回的时间怎么计算？nginx到tomcat之间的耗时怎么计算，tomcat-mysql之间的耗时如何计算？而自身nginx，tomcat，mysql处理逻辑或者业务的时间耗时又如何计算呢？作者回复: 这个我在专栏中有说明吧。
像nginx上就有request time和response time时间。tomcat也有。
mysql的处理逻辑或业务的时间耗时这句没看懂是什么意思？对SQL要看的是从执行到结束的每个环节。
2020-01-17您好 那是不是jmeter测试每秒500个用户并发 就是设置50个线程 Ramp-Up为1秒？作者回复: 不一定，要看响应时间是多长，做出有梯度的场景来。
- 2020-01-13老师，请问吞吐量怎么理解我一直没明白，吞吐量和TPS，响应时间之间有什么关系
作者回复: 通常我都不用吞吐量这个概念。因为它在不同人的脑子里会存在一些误解。
比如说，有些人说吞吐量就是在说TPS。有些人说吞吐量是说的每秒字节数。
所以不建议用这个概念来承载性能指标。有TPS就够了。 
2020-01-13有个问题面试官问了我 但是我忘记问答案了 并发数不高的情况下 数据库和应用服务器资源维持在70%左右 吞吐量一直在增加 但是TPS在下降 这个什么原因造成的作者回复: 这个问题需要详细的场景数据。你这样的描述没判断做分析判断哦。
- 2020-01-13首先2/8原则的业务模型划分就极为牵强，我认为IT行业业务变来变去玩的就是数据，没有数据来证明就下结论就跟耍流氓没啥区别，就相当与领导给你打绩效，没有说明你这个月有什么失误，认为给你一个表现不好的同事扣了绩效，也就给你扣了绩效，你难道就忍了？应该结合生产数据去做评估。
然后是2/5/8的响应时间，唉、都0202年了···不同行业，不同业务，不同场景~应该分别去对待吧。作者回复: 说的很对。我也这样认为。