• 飞翔
    2019-12-18
    如果这时响应时间是 100ms,那显然并发线程数是 500TPS/(1000ms/100ms)=50(并发线程)。 这没看明白是什么意思

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

     2
     9
  • @zzw
    2019-12-17
    第一个问题:
    这个命题的争论有个bug,问题在于「快、好」的定义上。做为不同业务下的性能水平,快的定义是不一样的,比如在数据处理业务中,常分OLAP(联机分析处理)、OLTP(联机事务处理),比如一个简单的 OLTP 查询有大厂是要求微妙级别的,OLAP 统计报表类的业务查询几分钟也是可以接受啊。

    第二个问题:
    在一个具体的业务场景中,性能场景中的业务模型和二八原则并没有什么关系,即使从宏观上来说有关系,也是很牵强的,至少至今为止,还没看到任何有数据和数学公式的支撑证明。
    展开

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

    
     8
  • nana
    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
  • rainbowzhouj
    2019-12-19
    第一个问题:
    不合理之处在于没有结合实际场景去规定它的响应时间。响应时间是否合理是要进行对比的,例如现在的大数据技术测试,在不同的条件配置下处理TB级的数据,响应时间半天、一天都可以说是合理的响应时间。因为影响响应时间的因素有很多(存储方式,调度方式,参数调优等),单独拿“258”说明是没有意义的。

    第二个问题:
    常识的适用情况在于通用,但实际场景中经常会有各种“意外”。以12306购票系统为例,以前春运抢票时经常会有朋友、家人吐槽12306好卡、好慢,我估计之前就是业务模型用了28原则,虽然已经进行过了压力测试、疲劳测试,但还是抵挡不住全国人民着急回家的心情,拼命的发送请求......所以实际情况要实际考虑,以通用估意外肯定会才很多坑,只有不断地优化,更新才能一步步满足用户地需要。(PS:现在12306系统已经好很多了)
    展开

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

    
     2
  • 漫漫
    2019-12-17
    一模一样,每个人都认为不是自己的问题

    作者回复: 所以就得有仲裁能力的人,而这个人就应该是性能测试团队中来,在我的工作经历中,我的团队就是干这个仲裁的事情。

    
     2
  • 吃饭睡觉打豆豆
    2019-12-16
    其实我觉得这个什么所谓的28,258,25810原则都是虚的,直接点就是测目前系统实际的并发数和吞吐量

    作者回复: 非常正的想法。响应时间从来都没有标准。

     1
     2
  • beyond
    2020-01-06
    可以讲讲其他性能指标么?比如常用数据库的、常用中间件的(Weblogic、kafka。。)等

    作者回复: 后面写。

    
     1
  • 餘生
    2019-12-23
    赞一个,对于刚做性能的我,这文章很好的查漏补缺。258原则那里之前一直被其他人误导,其实自己做的时候都觉得有点奇怪怎么还会按照258原则来做标准呢,现在这年代3秒都觉得慢了。。

    作者回复: 以讹传讹的理念根深蒂固。而战斗在一线的都深受其苦。

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

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

    
     1
  • miminiMei
    2019-12-19
    老师的声音好好听,可以一直听,反复听😉

    作者回复: 多谢鼓励。不过还是要关注技术重点哦。哈。

    
     1
  • 夜空中最亮的星(华仔...
    2019-12-17
    这一篇超值了

    作者回复: 有过性能经验的人都会有超值的感觉。哈哈。

    
     1
  • Geek_618ac5
    2019-12-17
    有点虚,都是讲一些 指标计算方式 不准,能否给一个准的? 新的刚开发的系统什么都没有,怎么收集线上业务数据?

    作者回复: 新开发的产品当然不是收集线上业务数据的方式。而应该来自于产品设计的团队,或同行业的数据比对。

     1
     1
  • 神一样的男子
    2019-12-16
    一口气看完三篇,很契合工作中的性能测试

    作者回复: 多谢支持。多交流。

    
     1
  • 呆熊
    2020-02-08
    QPS 和 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在下降 这个什么原因造成的

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

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

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

    
    
我们在线,来聊聊吧