zoukankan      html  css  js  c++  java
  • TPS和事物的平均响应时间 怎么个关系,有关系吗

    问者:每秒处理的事物数和事物的平均响应时间 怎么个关系,有关系吗 

    kaku21:举个例子:一个高速路 有10个入口,每个入口每秒钟只能进1辆车,请问1秒钟最多能进几辆车?? 

    问者:10 

    kaku21:每辆车需要多长时间响应?? 

    问者:针对这个问题的话 那tps就是10 ,事物的响应时间是1 

    kaku21:好,那现在我有20辆车,那每秒能进几辆??每辆响应时间是多少?? 
    问者:。。。思考中       

    kaku21:每秒还是进10辆车呗,每辆车还是1秒响应啊 

    问者:对呀 

    kaku21:继续,现在我把入口扩展到20个,那我问你,每秒最多进多少辆车??每辆车响应多长时间?? 

    问者:20  1 

    kaku21:好,现在tps变了,响应时间没变,那我问你 tps跟响应时间有啥关系?? 

    问者:没关系 

    kaku21: tps和响应时间在理想状态下都是额定值,你把入口看做线程池。如果20个入口,并发数只有10的时候,tps就是10,而响应时间始终都是1,说明并发不够,需要增加并发数达到tps的峰值。 

    问者:同样是20个入口,并发数是100的话,tps是20,响应时间还是1? 
    什么情况下响应时间会大于1秒 

    kaku21:我问你,当并发数量是100的时候,会出现什么情况?? 

    问者:堵车啦。。。哦,堵车了 平均每个车过去的时间就长了? 

    kaku21:堵车说白了就是有车在等待,现在把100按20分成5份,第5份等待的时间是最长的,从等待开始到这个车进去,实际花费了多长时间?? 

    问者:5秒吧 

    kaku21:那么100两车的平均响应时间是多少?? 

    问者:5除以100?0.05? 

    kaku21:错,用简单的数学逻辑算 (5+4+3+2+1)/5=3 这就是平均响应时间 

    明白没??接着问你,100两车的平均tps是多少?? 


    问者:20? 

    kaku21:错(20/1+20/2+20/3+20/4+20/5)/5 约等于 8.8999 

    问者:前面tps还是20呢 ,并发大了 怎么tps小了.20是tps的峰值? 

    kaku21:响应时间和TPS在宏观上是反比的关系,但是两者之间没有直接关系 

    kaku21:20是一次并发的数量,100的并发则造成了线程的等待,引起平均响应时间从1秒变成3秒,当然TPS也从20下降到9;TPS和响应时间都是单独计算出来的,两者不是互相计算出来的。

    .  背景

       在做性能测试的时候,很多人都用并发用户数来衡量系统的性能,觉得系统能支撑的并发用户数越多,系统的性能就越好;对TPS不是非常理解,也根本不知道它们之间的关系,因此非常有必要进行解释。

    2.  术语定义

    • 并发用户数: 指的是现实系统中操作业务的用户,在性能测试工具中,一般称为虚拟用户数(Virutal User),注意并发用户数跟注册用户数、在线用户数有很大差别的,并发用户数一定会对服务器产生压力的,而在线用户数只是 “挂”在系统上,对服务器不产生压力,注册用户数一般指的是数据库中存在的用户数。
    • TPS : Transaction Per Second,  每秒事务数, 是衡量系统性能的一个非常重要的指标,

    3.  Vu和TPS换算

        TPS是每秒事务数,但是事务是要靠虚拟用户做出来的,假如1个虚拟用户在1秒 内完成1笔事务,那么TPS明显就是1;如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务,TPS就是1000了;如果某笔业务 响应时间是1s,那么1个用户在1秒内只能完成1笔事务,要想达到1000TPS,至少需要1000个用户;因此可以说1个用户可以产生 1000TPS,1000个用户也可以产生1000TPS,无非是看响应时间快慢。

    4.  如何获取Vu和TPS

    • 并发用户数(Vu)获取

    新系统:没有历史数据作参考,只能通过业务部门进行评估。

    旧系统:对于已经上线的系统,可以选取高峰时刻,在一定时间内使用系统的人数,这些人数认为属于在线用户数,并发用户数取10%就可以了,例如在半个小时内,使用系统的用户数为10000,那么取10%作为并发用户数基本就够了。

    • TPS获取

    新系统:没有历史数据作参考,只能通过业务部门进行评估。

    旧系统:对于已经上线的系统,可以选取高峰时刻,在5分钟或10分钟内,获取系统每笔交易的业务量和总业务量,按照单位时间内完成的笔数计算出TPS,即业务笔数/单位时间(5*60或10*60)

    5.  如何评价系统的性能

       针对服务器端的性能,以TPS为主来衡量系统的性能,并发用户数为辅来衡量系统的性能,如果必须要用并发用户数来衡量的话,需要一个前提,那就是交 易在多长时间内完成(系统响应时间),因为在系统负载不高的情况下,将思考时间(思考时间的值等于交易响应时间)加到脚本中,并发用户数基本可以增加一倍,因此用并发用户 数来衡量系统的性能没太大的意义。

    • 系统响应时间:

    系统一次调用的响应时间跟项目计划一样,也有一条关键路径,这个关键路径就是系统响应时间,关键路径是由CPU运算、IO、外部系统响应等组成。

    响应时间= 网络传输时间 + 应用服务器处理时间 + 数据库服务器处理时间

    6.  相关案例

    通过大量性能测试我们发现不需要用上万的用户并发去进行测试,只要系统处理业务时间足够快,几百个用户甚至几十个用户就可以达到目的。另外咨询很多专家做过的性能测试项目,基本都没有超过5000用户并发。

    因此对于大型系统、业务量非常高、硬件配置足够多的情况下,5000用户并发就足够了;对于中小型系统,1000用户并发就足够了。

    7.  性能测试策略

    做性能测试需要一套标准化流程及测试策略,并发用户数只是指标考虑的一个,在做负载测试的时候,一般都是按照梯度施压的方式去加用户数,而不是在没 有预估的情况下,一次加几万个用户,,交易失败率非常高,响应时间非常长,已经超过了使用者忍受范围内,这样做没有多大的意义,这就好比“有多少钱可以干多少事”一样,需要选择相关的策略。

    8.  总结

    • 系统的性能由TPS决定,跟并发用户数没有多大关系。在同样的TPS下,可以由不同的用户数去压(通过加思考时间设置)。
    • 系统的最大TPS是一定的(在一个范围内),但并发用户数不一定,可以调整。
    • 建议性能测试的时候,不要设置过长的思考时间,以最坏的情况下对服务器施压。
    • 一般情况下,大型系统(业务量大、机器多)做压力测试,5000个用户并发就够了,中小型系统做压力测试,1000个用户并发就足够了。
  • 相关阅读:
    HDOJ 1207 汉诺塔II
    [转]写代码的小女孩
    POJ Subway tree systems
    HDOJ 3555 Bomb (数位DP)
    POJ 1636 Prison rearrangement (DP)
    POJ 1015 Jury Compromise (DP)
    UVA 10003
    UVA 103 Stacking Boxes
    HDOJ 3530 Subsequence
    第三百六十二、三天 how can I 坚持
  • 原文地址:https://www.cnblogs.com/BlogNetSpace/p/10858151.html
Copyright © 2011-2022 走看看