jmeter性能测试笔记

 

2Badboy

2.1 安装

Badboy配合jmeter使用,提供录制/回放功能。

安装Badboy,安装过程同一般的Windows应用程序没有什么区别,安装完成后你可以在桌面和Windows开始菜单中看到相应的快捷方式---如果找不到,可以找一下Badboy安装目录下的Badboy.exe文件,直接双击启动Badboy;

启动Badboy,你可以看到下面的界面

 

 

2.2 录制

1)打开badboy进行登录的录制工作。(我们来看下163邮箱的登录并发性能如何)

 

 

2)在地址栏输入:http://email.163.com/.点击红色按钮,设置为录制状态,点击绿色箭头开始录制,输入邮箱密码,点击登录,点击黑色结束录制按钮。

补充说明:

 

 

 

 

 

3)参数化

 

 

 

4)将录制的过程保存下来,保存成jmeter能够使用的格式,Script.jmx

 

 

 

 

3、单台模拟多用户测试

1)运行Apache Jmeter,文件打开,然后选择刚才保存的录制文件Script.jmx

2)设置模拟并发的线程数量,设置虚拟用户100,循环次数1

3Ramp-Up Period :加压时间设置为1秒,1秒内启动100个线程,即每一个线程都会在上一个线程启动0.01秒之后才开始运行,如果Ramp-Up Period设置为0,那么100个线程将同时启动,Jmeter将会在测试的开始就建立全部线程并立即发送访问请求,这样一来就很轻易使服务器饱和,更重要的是会隐性地增加了负载,这就意味着服务器将可能过载,不是因为平均访问率高而是因为所有线程的第一次并发访问而引起的不正常的初始访问峰值,可以通过Jmeter的聚合报告监听器看到这种现象。

 

 

3)添加感兴趣的监听类型

 

 

4)点击 运行-》启动,开始执行并发登录

 

5)分析结果

查看聚合报告:

 

 

其中:

Label:标签,

#Samples:本次场景中一共发出了多少个请求

Average:平均响应时间

Median:中位数,也就是50%的用户的响应时间

90%Line:表示90%的用户的响应时间,如果最小值和最大值相差很大的话,我们一般选择这个作为最终测试结果

Min:最小响应时间

Max: 最大响应时间   

Error%:出错率,本次测试中出现错误的请求的数量/请求的总数

Throughput:吞吐量

KB/sec:第秒从服务器端接受到的数据量

 

图形报表:

 

 

图表底部参数的含义如下:

样本数目是总共发送到服务器的请求数。 

最新样本是代表时间的数字,是服务器响应最后一个请求的时间。

吞吐量是服务器每分钟处理的请求数。

平均值是总运行时间除以发送到服务器的请求数。

中间值是代表时间的数字,有一半的服务器响应时间低于该值而另一半高于该值。

偏离表示服务器响应时间变化、离散程度测量值的大小,或者,换句话说,就是数据的分布。  

 

使用分析:

在测试过程中,平均响应时间是我们性能测试的一个重要衡量指标,

但是在测试中,特别是在聚合报告中,得出的90%Line,90%响应时间是说在发送的

请求中,90%的用户响应时间都能达到这个数值,那么就为系统性能分析提供了很好的参考价值。    

 

4、不录制,如何通过jmeter测试

当前我们需要模拟APP对后台的请求压力测试,由于APP部分无法通过badboy录制,可以通过直接调用后台接口,或模拟web页面的请求接口(appweb方式调用相同的后台接口的情况下)进行测试。

1.添加HTTP请求默认值

 

 

2.发送json格式的http请求的时候,需要添加HTTP信息头管理器设置Content-Type=application/json

 

 

3.添加Cookie管理器

 

4.根据接口文档来设计接口传递参数。

 

 

5. 配置CSV文件,进行参数化

 

 

123.CSV截图:

 

 

6.运行察看结果树,查看结果

 

 

7.登录成功,请求扫描二维码页面,登录不成功,不请求扫描二维码页面,添加如果(if)控制器,条件isSuccess==1,代表登录成功。

 

 

8.请求登录页面的下面添加正则表达式提取器。

 

 

 

9.执行,并观察结果

 

 

5jmeter分布式测试

作为一个纯 JAVA GUI应用,JMeter 对于CPU和内存的消耗还是很惊人的,所以当需要模拟数以千计的并发用户时,使用单台机器模拟所有的并发用户就有些力不从心,甚至还会引起JAVA内存溢出的错误。不过,JMeter 也可以像 LoadRunner 一样通过使用多台机器运行所谓的 Agent来分担 Load Generator 自身的压力,并借此来获取更大的并发用户数。根据 JMeter官方文档的署名,你需要自己完成这个配置,不过不用担心,这将非常简单 。

在进行分布式平台测试的时候,你先要检查一下以下的内容

1 所有的防火墙应该关闭

2 所有的客户端应该都是在同一个子网中。

3 确保jMeter可以访问这个服务器

4 确保各个客户端的jMeter的版本都是一致的,不同版本的Jmeter可能不会协同工作。

如果这些前提条件你都准备好了,那么你就可以开始远程测试了

jMeter的工作方式就是一个主机会去初始化其它从机的测试案例。系统的拓扑图如下。

 

逐步搭建Jmeter分布式平台

下面我们将一步一步地搭建这个平台

1. 在所有期望运行 JMeter 作为 Load Generator 的机器上安装 JMeter,并确定其中一台机器作为 Controller,其他的机器作为 Agent。然后运行所有 Agent 机器上的JMeter-server.bat文件——假定我们使用两台机器 192.168.0.11 192.168.0.12 作为 Agent

2. Controller 机器的 JMeter 安装目录下找到 bin 目录,再找到 JMeter.properties 这个文件,使用记事本或者其他文字编辑工具打开它;

3. 在打开的文件中查找“remote_hosts=”这个字符串,你可以找到这样一行“remote_hosts=127.0.0.1”。其中的 127.0..0.1 表示运行JMeter Agent 的机器,这里需要修改为“remote_hosts=192.168.0.11:1099,192.168.0.12:1099”——其中的 1099 JMeter ControllerAgent 之间进行通讯的默认 RMI 端口号;如图:

 

4.保存文件,并重新启动 Controller 机器上的 JMeter.bat,并进入 Run -> Remote Start 菜单项。

 

如果你想确认Agent 机器是否已经启动了,你可以用记事本打开bin目录下的jmeter文件,如果正常启动,应该可以看到以下的日志。

 

你可以启动单独一个slave系统,也可以同时启动所有的slave系统

 

 

1.所谓的 Agent,是指运行了 jmeter-server.bat 的那台机器;

2.所谓的 Controller,是指运行了 JMeterUI 客户端或者命令行方式)的那台机器;

3.Agent 可以和 Controller 运行在同一台机器上,也可以运行多个 Agent 在同一台机器上;只需要修改JMeter.properties文件,将ControllerIP地址写入。这时,需要先打开Controller电脑中JMeterbin目录下的jmeter-server.bat,然后再打开JMeter.bat,此时,进入Run -> Remote Start菜单,可以看到Controller也作为远程机器进行运行,如图:

 

 

4.JMeter 中不能对单个 Agent 设置并发用户数量,例如:有三个 Agent,你在 JMeter 中定义了 100 个并发用户,那么就是 3 Agent 每个都模拟 100 个用户,一共是 300 个。

 

6、现有实验室资源实际实践

6.1 测试要求

能够模拟10000用户同时在线并进行不同的业务,利用现有的资源对系统做性能测试,模拟手机APP扫描二维码后数据传入后台,对后台的服务器,硬件进行压力测试,能否支持10000个用户并发操作的要求。

 

6.2 所需资源

网络带宽:20M

服务器:Dell塔式服务器,T420E5-2407/4G/1T硬盘/DVD/H310/550W单电(192.168.0.116,root 123456)

Jmeter测试机:处理器:Inter(R)Core(TM)i5-4570 CPU @3.2GHz

安装内存(RAM4G

操作系统:windows7  32位   

  1. 虚拟用户400
  2. 网路带宽20MB

6.3 测试组网

Jmeter支持分布式测试,通过一台server控制多台主机的方式,用于模拟大用户数多业务并发测试。

 

 

 

 

 

 

 

 

 

6.4 详细步骤

 

 

 

 

 

 

常见问题FAQ

问题一:如何找到电脑最合适的加压用户数

解决方法:

指标值:

1.系统要求在线用户10000

2.1万级并发的情况下,保证以下业务的处理速度小于3秒:

系统在线用户并发数取在线用户数的30%,即:10000*30%=3000

此次性能测试用户数分三个档次:3000并发,3050并发,3100并发,3150并发。

并分别对三种情况进行性能测试记录测试结果并对测试结果进行分析。

系统响应时间判断原则(2-5-10原则)如下:系统业务响应时间小于2秒,判为优秀,用户对系统感觉很好;系统业务响应时间在2-5秒之间,判为良好,用户对系统感觉良好;系统业务响应时间在5-10秒之间,判为及格,用户对系统可以接受;系统业务响应时间超过10秒,判断为不及格,用户不能接受系统的响应速度;

问题二:

解决方法:

 

 

 

 

问题二:如何监控服务器CPU, Memory, Disks I/O

解决方法:

安装JMeter——PerfMon插件

PerfMon他就是用来收集被压服务器的各种性能指标,例如: CPU, Memory, Swap, Disks I/O and Networks I/O ……

 

 

                                                                                                                                                                                                                                                       

posted on 2018-01-03 16:51  胡薇  阅读(502)  评论(0编辑  收藏  举报

导航