详解Jmeter线程组的设置方法

目录
  • 一、事件背景
  • 二、关于线程组的相关设置

一、事件背景

个人感觉自己做性能测试，可以说是轻车熟路了，而且工作多年一直都是这一套测试思路及体系，从未质疑过自己，也许是狮子座的迷之自信吧！

也就在上周让我对自己的测试方法及体系产生了质疑！

为什么？在性能测试的时候，压测500并发通过，人家40并发都过不去。

通俗点说，就是你测试没问题，在人家那测试出问题了，忽略脚本问题，显而易见因为测试方法差异导致测试结果的不同。

1、关于执行方法的差异

  • 同事的做法是直接跑10分钟的稳定性测试，然后上并发数；
  • 我的做法一个用户循环访问一次，然后上并发数；

2、关于执行结果的差异

  • 同事这种方式比我的方式，对目标服务器的压力更大；
  • 体现在哪，如果循环次数选择了一旦选择了永远，即请求次数会比我的方式多，所以自然压力也大；

3、真的是我测试方法错了吗

我和同事分别测试两个系统，具体还是有些区别的：

  • 同事这边业务场景有40个接口，执行一次最多1分钟，要不就是20秒，具体没记清楚；
  • 我这边的业务场景有76个接口，执行一次大约50分钟，如果我直接上负载测试10分钟，根本跑不完一组业务场景；
  • 我去请教大周老师，老师说正常先要让跑一定的时间，可以查看是否稳定运行及测试结果是否一致准确，性能测试本就是多次测试的结果。

4、结论

我是在最后跑的稳定性测试，是8小时起步，从时间上看覆盖到了他的十分钟，而且压力更大。

但是，有些同学会问他测试的对吗，他的思路是对的，因为他执行一次业务场景，小于10分钟，在小批量并发测试师没问题的。

当然，如果并发量上来后，还是设置十分钟的话，会出现我那种情况 业务场景接口没执行完的情况，此处，大家自行尝试见分晓。

二、关于线程组的相关设置

我又去查了大量资料，终于找到了一篇我觉得比较在理的文章，并举例给大家演示，我觉得这个同学的理论好像是对的，因为我也测试了下，发现也吻合我的测试结果（算求生存吗？）！
下面我将举例说明，该方法。

1、执行第一次数据采样，得到吞吐率和平均响应时间

由图可知：

吞吐率=2.6≈3,平均响应时间：t=0.386秒；

2、计算ramp-up period

假设线程N=10，估计的吞吐率=3， 那么估计的理想ramp-up period (T)（可以理解为线程启动的准备时间）= 10/3 = 3 秒。

3、循环次数计算

现在计算循环次数A。由于我们要考虑在第一个线程结束的时候，确保最后一个线程能启动，那么至少要大于一个值，这个值定位S=T-T/N=3-3/10=2.7。

当时间到 S=（T-T/N）时，最后一个线程启动，若要使所有线程同时运作，则需要在最后一个线程启动的时候第一个线程仍未关闭，为达到这个要求，需满足A > S/t
A>2.7/0.386=6.994≈7次 A>(T-T/N)/t

4、得出的测试方案

那么我们的测试方案如下：

5、关于公式

到此这篇关于详解Jmeter线程组的设置方法的文章就介绍到这了,更多相关Jmeter线程组设置内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

赞 (0)

相关推荐

  • Jmeter跨线程组传值调用实现图解

    Jmeter的线程组之间是独立的,用Jmeter做接口测试或者是性能测试时,经常会涉及到多个线程组.那么如何将A线程组返回的变量信息提取后,传递给B,C线程组使用呢?这里以已登录接口返回的access_token值为例,在这里我用了一个BeanShell后置处理器来结合使用,过程如下: 第一步:测试计划:必须勾选[独立运行每个线程组] ​ 第二步:登录接口返回access_token ​ 第三步:通过正则表达式提取器提取:access_token ​ 第四步:在BeanShell后置处理器中使用

  • Jmeter线程组传参原理解析

    这篇文章主要介绍了jmeter线程组传参原理解析,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 背景介绍: 使用jmeter做登录和搜索接口的测试: 登录接口请求头为:Content-Type: application/x-www-form-urlencoded; charset=UTF-8 搜索接口请求头为:Content-Type: application/json; charset=UTF-8 同时,搜索的请求头中需要用到登录接口返回值中

  • Jmeter跨线程组共享cookie过程图解

    一.Jmeter版本 此次示例采用的是apache-jmeter-5.2.1版本 二.设置配置文件使Cookie管理器保存cookie信息. 修改apache-jmeter-5.2.1/bin/jmeter.properties文件,把CookieManager.save.cookies设置为true,并去掉前面的注释#号,如下图所示: ​ 修改完成后保存,退出,并重启jmeter. 三.在调试取样器和请求中查看具体的cookie信息 在线程组中添加HTTP Cookie 管理器,运行测试计划后

  • 基于jmeter实现跨线程组传递token过程图解

    遇到一些综合场景的设置,每个不同的请求并发数设置不同的时候,可以用多个线程组的组合来实现,但是这个时候,会遇到一个问题,那就是jmeter各个线程组之间是相互独立的,各个线程互不影响,所以线程组A中输出的参数,无法直接在线程组B中调用. 拿token来说,虽然每一个线程组中我们也可以在放一个登录请求,然后输出一个token供此线程组使用,但这样就比较繁琐且冗余.此时我们就可以使用跨线程组传递参数来解决这样的问题. 接下来,我们看下这个例子: 要发送短信,必须要先登录,才能发送. 实现思路: 在登

  • 详解Jmeter线程组的设置方法

    详解Jmeter线程组的设置方法

    目录 一.事件背景 二.关于线程组的相关设置 一.事件背景 个人感觉自己做性能测试,可以说是轻车熟路了,而且工作多年一直都是这一套测试思路及体系,从未质疑过自己,也许是狮子座的迷之自信吧! 也就在上周让我对自己的测试方法及体系产生了质疑! 为什么?在性能测试的时候,压测500并发通过,人家40并发都过不去. 通俗点说,就是你测试没问题,在人家那测试出问题了,忽略脚本问题,显而易见因为测试方法差异导致测试结果的不同. 1.关于执行方法的差异 同事的做法是直接跑10分钟的稳定性测试,然后上并发数:

  • Java详解使用线程池处理任务方法

    Java详解使用线程池处理任务方法

    什么是线程池? 线程池就是一个可以复用线程的技术. 不使用线程池的问题: 如果用户每发起一个请求,后台就创建一个新线程来处理,下次新任务来了又要创建新线程,而创建新线程的开销是很大的,这样会严重影响系统的性能. 线程池常见面试题: 1.临时线程什么时候创建? 新任务提交时发现核心线程都在忙,任务队列也满了,并且还可以创建临时线程,此时才会创建临时线程. 2.什么时候会开始拒绝任务? 核心线程和临时线程都在忙,任务队列也满了,新的任务过来的时候才会开始任务拒绝. 1.线程池处理Runnable任务

  • 详解Windows下的权限设置方法

    随着动网论坛的广泛应用和动网上传漏洞的被发现以及SQL注入式攻击越来越多的被使用,WEBSHELL让防火墙形同虚设,一台即使打了所有微软补丁.只让80端口对外开放的WEB服务器也逃不过被黑的命运.难道我们真的无能为力了吗?其实,只要你弄明白了NTFS系统下的权限设置问题,我们可以对crackers们说:NO! 要打造一台安全的WEB服务器,那么这台服务器就一定要使用NTFS和Windows NT/2000/2003.众所周知,Windows是一个支持多用户.多任务的操作系统,这是权限设置的基础,

  • 详解JAVA 线程-线程的状态有哪些？它是如何工作的？

    线程(Thread)是并发编程的基础,也是程序执行的最小单元,它依托进程而存在. 一个进程中可以包含多个线程,多线程可以共享一块内存空间和一组系统资源,因此线程之间的切换更加节省资源.更加轻量化,也因此被称为轻量级的进程. 线程的状态在 JDK 1.5 之后以枚举的方式被定义在 Thread 的源码中,它总共包含以下 6 个状态: NEW,新建状态,线程被创建出来,但尚未启动时的线程状态: RUNNABLE,就绪状态,表示可以运行的线程状态,它可能正在运行,或者是在排队等待操作系统给它分配 CP

  • 详解Java线程池和Executor原理的分析

    详解Java线程池和Executor原理的分析 线程池作用与基本知识 在开始之前,我们先来讨论下"线程池"这个概念."线程池",顾名思义就是一个线程缓存.它是一个或者多个线程的集合,用户可以把需要执行的任务简单地扔给线程池,而不用过多的纠结与执行的细节.那么线程池有哪些作用?或者说与直接用Thread相比,有什么优势?我简单总结了以下几点: 减小线程创建和销毁带来的消耗 对于Java Thread的实现,我在前面的一篇blog中进行了分析.Java Thread与内

  • 详解c# 线程同步

    一.线程同步概述 前面的文章都是讲创建多线程来实现让我们能够更好的响应应用程序,然而当我们创建了多个线程时,就存在多个线程同时访问一个共享的资源的情况,在这种情况下,就需要我们用到线程同步,线程同步可以防止数据(共享资源)的损坏. 然而我们在设计应用程序还是要尽量避免使用线程同步, 因为线程同步会产生一些问题: 1. 它的使用比较繁琐.因为我们要用额外的代码把多个线程同时访问的数据包围起来,并获取和释放一个线程同步锁,如果我们在一个代码块忘记获取锁,就有可能造成数据损坏. 2. 使用线程同步会影

  • 详解Java线程同步器CountDownLatch

    Java程序有的时候在主线程中会创建多个线程去执行任务,然后在主线程执行完毕之前,把所有线程的任务进行汇总,以前可以用线程的join方法,但是这个方法不够灵活,我们可以使用CountDownLatch类,实现更优雅,而且使用线程池的话,可没有办法调用线程的join方法的呀! 一.简单使用CountDownLatch 直接使用线程: package com.example.demo.study; import java.util.concurrent.CountDownLatch; public

  • 详解用Nginx搭建CDN服务器方法(图文)

    利用Nginx的proxy_cache搭建缓存服务器一:编译ngx_cache_purge 1.Nginx的Proxy_cache是根据Key值md5哈希存储缓存,支持任意的Key,例如你可以根据"域名.URI.参数"组合成key,也支持非200状态码,如404/302等. 2.要利用Nginx的Proxy_cache,你需要在Nginx编译进ngx_cache_purge 模块,执行:nginx -V,查看有没有ngx_cache_purge 字样,没有的话需要自己手动编译. Ngi

  • 详解Java 线程中断

    一.前言 大家肯定都使用过 Java 线程开发(Thread / Runnable),启动一个线程的做法通常是: new Thread(new Runnable( @Override public void run() { // todo sth... } )).start(); 然而线程退出,大家是如何做的呢?一般做法可能不外乎以下两种: 设置一个标志位:true / false 来退出: 强制退出:thread.stop:(我相信,现在应该没人会使用这种方式了,因为JDK也很早就废弃了该方法

  • 详解C# 线程的挂起与唤醒

    如果说C#和C++有什么不同,博主不得不说,对于异步的支持程度是C#的一一个伟大的进步. 其实早期的C++都没有异步,并发的概念.博主第一次使用C++创建异步程序的时候,是使用boost库的内容进行实现的.相对而言,C#对于异步的支持可以说是相当的好.相信很多名词大家都很耳熟能详,比如说Thread,BeginInvoke,Delegate,backgroundworker等等...其实楼主在使用了这么多的异步操作过程中,还是觉得backgroudworker比较好用. 当然,我们今天要说的和上

随机推荐