Jmeter笔记

Jmeter 5.0 安装及环境变量设置

Mac：安装 Brew， Wget 等 下载安装 JDK8 https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html java -version # 检查JDK版本 /usr/libexec/java_home -V # 列出 JAVA_HOME 配置环境变量 vim ~/.bash_profile echo $JAVA_HOME，echo $PATH，echo $CLASSPATH

下载 Jmeter

http://jmeter.apache.org/download_jmeter.cgi

export JMETER_HOME=/Users/macman/tools/apache-jmeter-5.1.1 export PATH=$JAVA_HOME/bin:$PATH:.:$JMETER_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JMETER_HOME/lib/ext/ApacheJMeter_core.jar:$JMETER_HOME/lib/jorphan.jar:$JMETER_HOME/lib/logkit-2.0.jar

source ~/.bash_profile Jmeter

性能拐点：

当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作。 但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；当系统负载大于最大并发用户数时，将注定会导致某些用户无法承受超长的响应时间而放弃。

性能测试对应场景举例：

  1. 能力验证： 用途：给定软硬件条件下，系统预期表现。 场景：指定AVG time要求，单系统能否支撑指定量级压力，例如5000qps 特点：通常指单机，指定硬件环境，明确并发和性能指标

  2. 容量规划： 用途：为满足需求，需要多少机器，如何部署 场景：指定用户量级，例如50W uv,需要多少台机器 特点：通常用于活动，新用户上线部署，不断探测得到系统承载能力

  3. 问题追查，风险发现 用途：在已有系统上，通过时间压力，查看资源使用，内存泄露情况 场景；在线时间24小时，高qps场景下验证full GC < 1s，无内存泄露 特点：长时间发压，关注性能指标，多次优化重试。

系统性能指标：

  1. RT(Response Time):交易响应时间 在线实时交易： 互联网企业：5000ms以下，例如淘宝业务10ms左右。 金融企业：1s以下为佳，部分复杂业务3S以下 保险企业：3s以下为佳 制造业:5s以下为佳 批量交易： 时间窗口：不同数据量结果不一样，大数据量的情况下，2小时内完成

  2. 系统处理能力（QPS） TPS(Transaction per Second):系统每秒处理交易数，比如支付流程，单位是笔/s. QPS(Query per Second):系统每秒处理查询次数，单位是次/秒。对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS， 一般情况下用TPS来衡量整个业务流程，用QPS来衡量接口查询次数 金融行业：1000TPS~9000TPS，不包括互联网化的活动 保险行业：100TPS~1000TPS，不包括互联网化的活动 制造行业：10TPS-50TPS 互联网电子商务：1万TPS-10万TPS 互联网中型网站：100TPS~500TPS 互联网小型网站：50TPS~100TPS

  3. 并发用户数（VU）比如1S内对同一商品双十一的秒杀；多用户对不同商品进行秒杀。同一时间没那么绝对。没有绝对的同一时间，而是同一单位时间范围内，比如1s

  4. 错误率（FR/ER ） 错误率是指系统在负载情况下，失败交易的概率，错误率=（失败交易数/交易总数）*100% 稳定性较好的系统，其错误率应该由超时引起，即为超时率。

  5. 稳定性指标：最短稳定时间：系统按照最大容量的80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间

  6. 异常恢复测试。熔断手段，限流手段。

性能测试流程：

  1. 需求分析与测试设计 前期根据相关人员沟通，初步确定压测方案及具体指标，完成性能测试设计后，需产出测试方案文档发送邮件到项目组，确认是否满足需求
  2. 环境设计与搭建 根据需求，结合线上机器部署情况，搭建线下测试环境，要求具有一定的参考价值，一般同比1/2,1/4；
  3. 数据的准备
  4. 性能指标预期 每秒请求数，请求响应时间（最小，最大，平均），错误率，机器性能：cpu idle 30%,memory无剧烈抖动或者飙升，压测过程接口功能是否正常
  5. 起压工具配置及测试脚本的编写
  6. 测试过程
  7. 结果分析与测试报告

线上全链路压测：why

系统复杂度高，服务多杂，核心链路长，压测环境难以构造，单机压测不准确，业务依赖重，第三方依赖多

难点：压测线上对服务影响，对数据影响，统计影响，对第三方依赖造成压力，修复困难 生成环境上基础的数据基本分为两种方式， 一，数据库层面不需要做改造，直接基于基础表里的测试账户，压测之后将相关的测试产生的流水数据清除（清除的方式可以sql脚本或者落在系统上） 二，压测流量单独打标（如单独定义Header）,然后业务处理过程中识别这个，并传递下去，包括异步消息和中间件，最终落到数据库的影子表或者影子库中

常用信息：

  • 线程组 线程组元件是任何测试计划的七点，一个测试计划的所有元件必须在一个线程组下。线程组元件控制Jmeter运行测试时使用的线程数。线程组元件包括下面3个参数： 1.设置线程数（相当于lr的虚拟用户的概念） 2.设置ramp-up period(in seconds)，阶段性起压，而不是一次达到某个线程数 3.设置循环次数

  • 采样器 采样器（sampler,又叫取样器）告诉Jmeter发送一个请求到指定服务器，并等待服务器的请求，采样器会按照其在测试树中的顺序去执行，还可以用逻辑控制器来改变采样器运行的重复次数

  • 逻辑控制器 可以帮助用户控制Jmeter的测试逻辑，特别是何时发送请求，逻辑控制器可以改变其子测试元件的请求执行顺序。

  • 监听器（Listener） 提供了对Jmeter在测试期间收集到的信息的访问方法。‘图像结果’监听器会将系统响应时长绘制在一张图片之中。‘查看结果树’监听器会展示采样器请求和响应的细节， 还可以将测试数据导入到文件之中，以供后续分析。

  • 定时器 定时器（Timer）会让作用域内的每一个采样器都在执行前等待一个固定时长，如果不设定这种延迟，Jmeter可能会在短时间内产生大量的访问请求，导致服务器被大量请 求所淹没。如果线程组加了多个定时器，那么Jmeter会将这些定时器的时长叠加起来，共同影响作用域范围内的采样器。定时器可以作为采样器或者逻辑控制器的子项，目的是只影响作用域内的采样器

*断言 用户可以使用断言（Assertions）来检查从服务器获得的响应内容。通过断言可以测试服务器返回的响应与测试人员的期望是否相符。 在Jmeter中，断言就类似于LR中的检查点，但比LR中的检查点功能强大。它对上一个请求返回的信息，可以做字符串、数据包大小、HTML,XML、图片等做判断，确保返回信息的准确性。

Jmeter八大元件

Sampler(取样器)：不与其他元件发生交互的作用的元件 Logic Controller（逻辑控制器）:只对其子节点和sampler有效，而其他元件需要与sampler等元件交互。 Config Element(配置元件)：影响其范围内的所有元件 Pre-processors(前置处理器)：在其作用范围内的每一个sampler元件之前执行 Timer（定时器）：对其作用范围内的每一个sampler有效 Post-processors(后置处理器)：在其作用范围内的每一个sampler元件之后执行 Assertions(断言)：对其作用范围内的每一个sampler元件执行后的结果执行校验 Listener(监听器)：收集其作用范围内的每一个sampler元件的信息并且呈现出来

八大元件的相互作用

Sampler独立，因此不存在作用域问题 Logic Controller仅对其子节点中的sampler生效 其他元件，如果sampler的子节点，则仅对其父节点作用 除Samper和Logic Controller外的其他寄原件，如果其父节点不是sampler,作用域是该元件父节点下的其他所有后代节点包括（包括子节点，子节点的子节点等）

八大元件执行顺序

Config Element Pre-processors Timer Sampler Post-processors Assertions Lisener

参数化：

函数助手：CSVRead CSV data set config: CSV 数据控件 User Defined Variables: 用户自定义变量 User Variables: 用户参数

并发与场景设计：

网站稿件管理核心系统当前生产环境高峰日交易总量为7500笔。根据二八原则（80%的交易量发生在20%的时间段内，当前生产环境对主机的交易吞吐量指标要求为：）， TPS_1 >= 7500(交易)80%（交易量）/（24h20%3600(1h=60min1min60s)）=0.34 笔/s 根据规划，网站稿件管理系统未来1年内核心系统的处理能力应达到高峰日交易总量10000笔，则3年后对主机的交易吞吐量指标要求为： TPS_2 >= 10000 * 80% /(2420%3600) = 0.46笔/s

Jmeter JVM配置

文件Jmeter.bat/Jmeter.sh中JVM配置如下，可根据项目具体情况调整 set HEAP=-Xms1g -Xmx1g XX:MaxMetaspaceSize=256m 2g 3g 32位操作系统建议配置heap size最大最小均为1G set HEAP=-Xms1024m -Xmx1024m

Jmeter分布式执行

一台作为调度机（master）,其他机器做为执行机（slave），执行时，master会把脚本发送到每台slave 上并发起执行，slave执行时通过cmdline执行完成后，slave会把结果回传给master,master会收集所有的slave的信息并汇总

配置执行机（slave）远程启动端口

修改配置文件：JMETER_HOME/bin/jmeter.properties中如下信息即可完成配置执行机远程启动端口（默认为1099） server_port=8012 server.rmi.localport=8012 添加执行机（Master） 路径：JMETER_HOME/bin/jmeter.properties,添加如下所示的执行机信息（IP为示例，请配置正确的执行机ip和端口） remote_hosts=192.168.1.X:8012,192.168.1.X:8012

启动执行机 jmeter -n -t script.jmx -R server1,server2,…

Written on May 18, 2019