zoukankan      html  css  js  c++  java
  • 大话性能测试系列(3)- 常用的性能指标

    如果你对性能测试感兴趣,但是又不熟悉理论知识,可以看下面的系列文章

    https://www.cnblogs.com/poloyy/category/1620792.html

    两种性能指标

    • 业务指标
    • 技术指标

    通常我们会从两个层面定义性能场景的需求指标,它们有映射关系,技术指标不能脱离业务指标

    并发

    狭义

    指同一个时间点执行相同的操作(如:秒杀)

    广义

    • 同一时间点,向服务器发起的请求(可能是不同的请求)
    • 只要向服务器发起请求,那么服务器在这一时间点内都会收到请求(不管是不是同一个请求)

    场景类比

    高速公路上,同时有多少辆车经过同一个关卡,但不一定是同一个牌子的汽车

    并发用户数(重点)

    同一时间点,发出请求的用户数,一个用户可以发出多个请求

    和并发的关系

    假设有 10 个用户数,每个用户同一时间点内发起 2 个请求,那么服务器收到的请求并发数就是 20

    相关概念

    • 系统用户数:系统累计注册用户数,不一定在线
    • 在线用户数:在线用户可能是正常发起请求,也可能只是挂机啥操作都没有【在线用户数并发用户数】
    • 线程数:在 jmeter 中,线程数和并发用户数等价

    事务

    • 客户端向服务器发送请求,然后服务器做出响应的过程
    • 登录、注册、下单等功能都属于一个事务
    • 一个事务可能会发起多个请求

    jmeter 相关

    jmerter 中,默认一个接口请求,就是一个事务;但也支持多个接口整合成一个事务

    注意点

    若一个业务或事务有多个接口,那么多个单接口的性能指标值相加 业务或事务的性能指标值

    再来看看有哪些常见的性能指标值

    响应时间(Respose Time)

    概念:从发起请求到收到请求响应的时间

    包含:Request Time 和 Response Time

    等价:发起请求网络传输时间 + 服务器处理时间 + 返回响应网络传输时间

    重点

    在做性能测试时,要尽可能的降低网络传输时间,这样最终得出的 RT 会无限接近服务器处理时间,所以我们要把网络环境搞好

    事务请求响应时间

    完成单个事务所用的时间,可能包含了多个请求

    TPS(Transaction Per Second,最主要的指标)

    服务器每秒处理事务数,衡量服务器处理能力的最主要指标

    知道 T 是如何定义的

    • 在不同的行业、业务中,TPS 定义的颗粒度可能是不同的
    • 所以不管什么情况下,需要做性能测试的业务的相关方都要知道你的 T 是如何定义的 

    定义 TPS 的粒度

    • 一般会根据场景的目的来定义 TPS 的粒度
    • 接口层性能测试:T 可以定义为接口级
    • 业务级性能测试:T 可以定义为每个业务步骤和完整的业务流

    栗子

    如果要单独测试接口 1、2、3,那么 T 就是接口级

    如果从用户角度下订单,那 1、2、3 都在一个 T 中,就是业务级

    结合实际业务设计,库存服务一定是同步,而积分服务可以是异步,所以这个下单业务,可以只看作由 1、2 这两个接口组成,但是 3 接口还是要监控分析的

    所以,性能中 TPS 中 T 的定义取决于场景的目标和 T 的作用

    拿上图做个例子

    接口级脚本

    ——事务 start(接口 1)

    接口 1 脚本

    ——事务 end(接口 1)

    ——事务 start(接口 2)

    接口 2 脚本

    ——事务 end(接口 2)

    ——事务 start(接口 3)

    接口 3 脚本

    ——事务 end(接口 3)

    业务级接口层脚本(就是用接口拼接出一个完整的业务流)

    ——事务 start(业务 A)

    接口 1 脚本 - 接口 2(同步调用)

    接口 1 脚本 - 接口 3(异步调用)

    ——事务 end(业务 A)

    用户级脚本

    ——事务 start(业务 A)

    点击 0 - 接口 1 脚本 - 接口 2(同步调用)

    点击 0 - 接口 1 脚本 - 接口 3(异步调用)

    ——事务 end(业务 A)

    总结

    一般情况下,我们会按从上到下的顺序一一来测试,这样路径清晰地执行,容易定位问题

    QPS(Queries per Second)

    • 每秒查询率,在数据库中每秒执行 SQL 数量
    • 一个请求可能会执行多条 SQL
    • 某些企业可能会用QPS代替TPS
    • 也是衡量服务端处理能力的一个指标,但不建议使用

    RPS(Request per Second)

    简单理解

    每秒请求数,用户从客户端发起的请求数

    深入挖掘

    对于请求数来说,也要看是哪个层面的请求,把上面的图做一点点变化来描述请求数

    如果一个用户点击了一次,发出来 3 个 HTTP Request,调用了 2 次订单服务,调用了 2 次库存服务,调用了 1 次积分服务

    问:Request 数量如何计算

    答:3+2+2+1 = 8?不, 应该是 3,因为发出了 3 个 Request,而调用服务会有单独的描述,以便做性能统计

    HPS(Hit per Second)

    • 点击率,每秒点击数
    • 有直接理解为用户在界面上的点击次数
    • 一般在性能测试中,都用来描述 HTTP Request,那它代表每秒发送 HTTP 请求的数量,和 RPS 概念完全一样
    • HPS 越大对 Server 的压力越大

    CPS/CPM(Calls Per Second/ Calls Per Minutes)

    • 每秒/每分钟调用次数
    • 通常用来描述 Service 层的单位时间内被其他服务调用的次数

    栗子

    上图的订单服务、库存服务、积分服务,各调用了2、2、1次,还是比较好理解的

    TPS、QPS、RPS、HPS、CPS 的总结

    有很多维度可以衡量一个系统的性能能力,但是如果把五个指标同时都拿来描述系统性能能力的话,未必太混乱了

    为此我们可以这样做

    • TPS 来统一形容系统的性能能力,其他的都在各层面加上限制条件来描述,比如说:接口调用 1000 Calls/s
    • 在团队中要定义清楚术语的使用场景,还有含义

    吞吐量(Throughput)

    单位时间内,网络处理的请求数量(事务/s)

    网络没有瓶颈时,吞吐量≈TPS

    吞吐率

    单位时间内,在网络传输的数据量的平均速率(kB/s)

    资源利用率

    • 服务器资源的使用程度,比如服务器(应用、服务器)的CPU利用率,内存利用率,磁盘利用率,网络带宽利用率
    • 一般不超过80%

    结尾

    本篇博文,部分参考了高老师的《性能测试实战30讲》,因为指标那一块讲的特别好哦~

  • 相关阅读:
    mhWaveEdit 1.4.8
    FFmpeg — 屏幕录制器材
    GNOME 主题: Troll
    cGmail — 主动反省邮件
    最小化布置 Ubuntu
    GNOME Do — 疾速翻开法式和文件
    PyTone 一个控制台音乐播放器
    高恪守编辑器 VIM-把持篇(2)
    Cankiri:玲珑实用的屏幕录像机
    LiVES 0.9.6pre4
  • 原文地址:https://www.cnblogs.com/poloyy/p/13130623.html
Copyright © 2011-2022 走看看