zoukankan      html  css  js  c++  java
  • jmeter压力测试

    jmeter压力测试

    概述

    大部分新手在用jmeter做压力测试的时候,对一些性能术语十分模糊,直接导致的后果就是对测试出来的结果数据根本不能理解,更谈不上分析了。今天的文章就着重给大家解释一下压力测试中的一些专有名词

    问题1:什么是压力测试

    问到如何做压力测试,很多人可能只会回答:"加线程组,加并发,看结果"。那么什么是压力,压力从哪里体现?这些恐怕就不得而知了。。。

    到底什么是压力呢?实际上我们在压力测试中用RPS来表示

    是不是有点懵了?什么是RPS呢?

    RPS 就是每秒请求数(Request Per Second),它描述了施压引擎向服务器实际发出的压力大小。

    Rps 由并发数和服务器响应时间决定。并发数过低时可能达不到预期的 RPS,并发数过高时可能压力过大直接就压垮了服务器。

    问题2:jmeter怎么调节压力

    从前面的描述中我们已经知道压力就是每秒发出的请求数。现在再来理解一个名词Ramp-up-period(in seconds)

    jmeter在线程组中有一个可调节的数值:Ramp-up-period,它表示启动所有线程需要的时间,单位是秒

    如下图,我设置了100个线程,迭代次数=1,Ramp-up-period=25,那么它表示我将在25秒内启动100个线程,也就是每秒钟启动4个线程。

    每个线程启动之间的间隔时间是25/100=0.25s,也就是250ms。

    换个理解方式,它表示了我们预期给服务器的压力就是每秒钟发送4个请求。也就是说,设置的RPS=4/s

    如下图,现在是不是能理解一些了?

     jmeter中的RPS是无法通过监听器来直观的监测到,但是可以通过侧面方式去验证一下。

    下图右上角能清晰的看出,我们100个线程用了25s才完全加载,或者说我们用了25s才成功的把100个请求发出去。那么每秒的请求就是4

    因为我们的脚本是单接口,所以理论上来说,此时的TPS=HPS=RPS.下图可以看出我们的几个指标都是4/s。

    HPS

     

    TPS

     

    问题3:jmeter中的throughput到底是什么?

    各位小伙伴们在使用jmeter时,是不是常常被 throughput 搞晕?到处都是throughput ,到底是做什么用的呢?

    我们先来看看有哪些throughput 元件

    定时器中有目标Constant Throughput 和 Throughput Shaping Timer

     

    逻辑控制器中有吞吐量控制器

     聚合报告中也有一个Throughput

    撑不住了,好晕啊。。。啊。。。啊。。。。

    稳住不要晕倒,下面带大家一个个的来梳理,重建jmeter世界观

    先来理解一下什么是Throughput

    Throughput是用来衡量吞吐量的指标,通常由TPS和QPS来表示。

    TPS表示每秒通过的事物数,QPS表示每秒查询接口数。

    jmeter中如果只有单接口,那么TPS=QPS。

    如果是多接口的混合场景,只有在事物控制器下执行,才能将其理解为TPS。

    聚合报告中的 Throughput

    下图Throughput表示无限迭代下的业务吞吐量TPS,大约是99/s。意思就是每秒能处理99笔事物。

    或者可以理解为:每秒能处理完成的请求数是99

    Constant Throughput Timer

    现在我们在接口下添加一个 Constant Throughput Timer

    这是一个吞吐量定时器,它可以控制我们的TPS。

    如图,我设定了目标吞吐量是240/min,也就是4/s。

    接下来运行的结果可以看到,无论我们预期的吞吐量有多大,实际的TPS都被强力压缩在4/s,同时我们的平均响应时间也变的很短

    Throughput Shaping Timer

    再来看一下 Throughput Shaping Timer

    下图可以很明显看到它是用来控制RPS的,也就是每秒请求数。

    start=1 end=100,持续时间是60。表示我们需要在60s内将RPS(每秒请求数)均匀的从1提升到100。

    下面可以看出来我们的每秒请求数均匀的在提升

    逻辑控制器-吞吐量控制器

    这个控制器里的吞吐量,指的是请求比例。

    比如我们总共发出9000个请求,这个控制器下的接口只会发送3000个,比例控制在30%

    下面这张图更直观的说明了请求的比例分配

    login1的控制器分配的比例是30%,剩余的70%都分给了login2的控制器

  • 相关阅读:
    抓取六房间小姐姐小视频
    fiddler报错:creation of the root certificate was not successful 证书安装不成功
    修改cmd命令默认路径
    二维码的生成
    大话设计模式Python实现-单例模式
    大话设计模式Python实现-迭代器模式
    大话设计模式Python实现-组合模式
    大话设计模式Python实现-备忘录模式
    大话设计模式Python实现-适配器模式
    大话设计模式Python实现-状态模式
  • 原文地址:https://www.cnblogs.com/Leo_wl/p/11070433.html
Copyright © 2011-2022 走看看