• 性能相关知识


    1.  背景

       在做性能测试的时候,很多人都用并发用户数来衡量系统的性能,觉得系统能支撑的并发用户数越多,系统的性能就越好;对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个用户并发就足够了

    如何评估系统的性能是否稳定

    一个正常的系统,在不断加压的过程,应该经历下面五个阶段:

    Ø 第一阶段:并发用户逐渐增加,系统的TPS(每秒处理事务笔数)逐步增大,直到达到最大值,这一阶段事务的响应时间不会有太大变化,会非常稳定;

    Ø 第二阶段:并发用户继续增加,TPS基本维持在最大值不变,但响应时间将会逐步变长。

    Ø 第三阶段:并发用户继续增加,TPS将会有少量下降(20%以内),但是决不能快速急剧下降,响应时间仍会逐步变长。

    u 本阶段可以拒绝服务,但是不能宕机。

    Ø 第四阶段:并发用户逐步减小,系统处理能力开始得到恢复,TPS能够逐步恢复到之前的最大值,响应时间开始变短;

    Ø 第五阶段:压力逐步降为零,TPS继续降低,响应时间继续变快,所有占用的CPU/内存/IO资源得到释放。

    引用:https://blog.csdn.net/taric_ma/article/details/77285522

    https://blog.csdn.net/xianyoudianxueyuan/article/details/47859119

  • 相关阅读:
    Enterprise Library系列文章回顾与总结
    .NET设计模式系列文章
    从Google趋势看.NET下的Ajax框架
    Atlas学习手记(18):使用DragPanel实现拖放面板
    Atlas学习手记(2):全面了解ScriptManager
    .NET设计模式(17):命令模式(Command Pattern)
    Atlas学习手记(3):由UpdatePanel开始
    Atlas学习手记(16):使用PasswordStrength检测密码强度
    Atlas学习手记(17):使用FilteredTextBox过滤字符
    用Windows Live Writer在博客园发布Post
  • 原文地址:https://www.cnblogs.com/tangqiu/p/10071152.html
Copyright © 2020-2023  润新知