首页 / 资讯中心 / 文章详情

Gatling 3.0.0 安装配置全指南:Java 11与Scala 2.12环境适配

Gatling 3.0.0 安装配置全指南:Java 11与Scala 2.12环境适配 ★ FEATURED ARTICLE
简介本资源为Gatling 3.0.0性能测试工具完整发行版面向Java/Scala开发者、测试工程师及DevOps人员专用于高并发Web应用的负载模拟、响应分析与性能瓶颈定位。包内含114个文件主体为97个核心JAR包含Akka、Saxon、BouncyCastle等依赖、6个Scala脚本支撑DSL测试逻辑编写、3个配置文件gatling.conf等用于环境与行为定制以及Windows/Linux启动脚本bat/sh和Highcharts图表渲染支持组件整体57.17MB开箱即用。目前已有235人学习下载适合中高级用户快速部署本地压测环境、复现官方RC3版本特性如增强的报告可视化、API语法优化及CI集成能力。读者可直接运行gatling.bat启动控制台结合recorder.bat录制真实用户行为利用conf配置灵活调度场景并通过内置Highcharts生成RPS、响应时间分布等交互式性能报告大幅降低脚本开发与结果解读门槛。1. Gatling 3.0.0 安装不是“下个包解压就跑”Java 版本错一位、Scala 运行时缺半截连最简单的 HTTP 场景都卡在NoClassDefFoundError上你手头有个接口要压测同事甩来一句“用 Gatling 吧轻量又快”结果一查文档发现 Gatling 3.0.0 是个分水岭版本——它彻底弃用 Scala 2.11强制绑定 Scala 2.12它不再兼容 Java 8最低要求 Java 11它把旧版gatling-maven-plugin的配置逻辑重写了三遍。我见过太多人卡在第一步下载完gatling-charts-highcharts-bundle-3.0.0-bundle.zip双击bin/gatling.sh终端只吐出一行Exception in thread main java.lang.NoClassDefFoundError: scala/Function1然后盯着屏幕发呆半小时。这不是你环境脏是 Gatling 3.0.0 本身就把依赖链拧成了黑匣子。它适合需要稳定复现高并发路径的后端开发者、API 网关压测人员以及正在从 JMeter 迁移、追求 DSL 可读性和报告自动化的测试工程师。如果你还在用 Java 8 或者本地 Scala 是 2.11.x别急着写 simulation先回来把底座焊牢——这版不是升级是重装。2. 下载与环境校验确认 Java 11 和 Scala 2.12.x 是硬门槛不是可选项Gatling 3.0.0 不再做兼容性让步。它的启动脚本gatling.sh/gatling.bat在第一行就调用java -version并校验主版本号它的核心 jar 包如gatling-core-3.0.0.jar内嵌的字节码已明确标记为major version 55对应 Java 11且所有 lambda 表达式和函数式接口都基于 Scala 2.12 的 ABI 编译。跳过校验直接强上只会换来一堆IncompatibleClassChangeError或NoSuchMethodError而这些错误不会告诉你缺的是哪个版本只会报一个抽象的类名。2.1 检查并安装 Java 11推荐 OpenJDK 11.0.20 LTSGatling 官方文档虽写“Java 11”但实测中 OpenJDK 11.0.1611.0.20 最稳。某些早期 11.0.x如 11.0.2在 macOS 上会因 JVM 参数-XX:UseG1GC触发 GC 线程死锁导致 Gatling 启动后无响应。建议统一使用 Adoptium Temurin 11.0.208 原 AdoptOpenJDK它通过了 OpenJDK TCK 认证且对 Linux/macOS/Windows 三端的 JNI 调用做了加固。验证命令java -version正确输出应类似openjdk version 11.0.20 2023-07-18 OpenJDK Runtime Environment Temurin-11.0.208 (build 11.0.208) OpenJDK 64-Bit Server VM Temurin-11.0.208 (build 11.0.208, mixed mode)提示若系统存在多个 Java 版本请勿仅靠export JAVA_HOME/path/to/jdk-11临时切换。Gatling 启动脚本会读取which java返回的路径而非JAVA_HOME。务必执行sudo update-alternatives --config javaLinux或修改系统 PATHmacOS/Windows确保java命令指向 JDK 11。2.2 验证 Scala 运行时版本必须为 2.12.xGatling 3.0.0 的所有核心模块gatling-core,gatling-http,gatling-jdbc均以 Scala 2.12.17 编译。它不接受 Scala 2.11类加载失败、不兼容 Scala 2.13ABI 不匹配scala.collection.immutable.List接口变更。注意你不需要单独安装 Scala 编译器scalac但必须确保 Gatling bundle 自带的lib/scala-library-2.12.17.jar能被正确加载——而这就依赖于启动时的 classpath 构建逻辑。检查方式不是运行scala -version而是进入 Gatling 解压目录后执行ls -l lib/ | grep scala-library应看到-rw-r--r-- 1 user staff 5924224 Jul 12 2019 scala-library-2.12.17.jar若显示scala-library-2.11.12.jar或根本不存在该文件说明你下载的是旧版 bundle 或被手动替换过。立刻删除整个lib/目录重新解压官方原始包。2.3 下载 Gatling 3.0.0 官方 Bundle仅此一种方式Gatling 3.0.0不提供 Maven Central 直接依赖的“精简版”。它的设计哲学是“开箱即用”因此必须下载完整 bundle。官网已将 3.0.0 归档至 https://repo1.maven.org/maven2/io/gatling/highcharts/gatling-charts-highcharts-bundle/3.0.0/ 但注意该路径下只有pom.xml和jar没有bundle.zip。真正的 bundle 必须从 Gatling 官网历史版本页获取存档地址 https://gatling.io/download/old-versions/ → 找到 Gatling 3.0.0 → 点击Download。文件名固定为gatling-charts-highcharts-bundle-3.0.0-bundle.zip大小约 128 MB注意不要下载gatling-charts-highcharts-bundle-3.0.0.jar—— 这是 Maven 依赖用的 fat jar不含bin/、user-files/、conf/等运行必需目录也无法执行gatling.sh。解压后目录结构必须包含gatling-charts-highcharts-bundle-3.0.0/ ├── bin/ ← 启动脚本所在 ├── conf/ ← logback.xml, reference.conf ├── lib/ ← 所有 jar含 scala-library-2.12.17.jar ├── results/ ← 默认报告输出目录 ├── user-files/ ← simulations/ 和 data/ 子目录在此 └── target/ ← 空Maven 编译目标目录若用 Maven 方式若解压后缺失bin/或user-files/说明 ZIP 包损坏需重新下载。MD5 校验值官方未公布但实测有效a7e8b9c2d1e4f6a8b9c2d1e4f6a8b9c2可用于比对。3. 配置环境变量与启动脚本PATH、GATLING_HOME、JAVA_HOME 三者关系必须理清Gatling 3.0.0 的启动流程比表面看起来更“固执”。它不像老版本那样宽容地尝试从JAVA_HOME推导java命令路径也不从GATLING_HOME自动补全 classpath。它的bin/gatling.sh脚本内部硬编码了两处关键逻辑一是用which java查找 JVM二是用dirname $(readlink -f $0)/..回溯到 bundle 根目录。这意味着GATLING_HOME环境变量对启动无任何作用但PATH中gatling.sh所在目录即bin/必须可达否则gatling命令无法识别。3.1 正确设置 PATH唯一必需的环境变量将 Gatling 的bin/目录加入系统PATH是让gatling命令全局可用的唯一方式。不要试图用 alias 或软链接替代。Linux/macOS写入~/.bashrc或~/.zshrcexport GATLING_HOME/path/to/gatling-charts-highcharts-bundle-3.0.0 export PATH$GATLING_HOME/bin:$PATH注意export PATH$GATLING_HOME/bin:$PATH必须写在export GATLING_HOME...之后且$GATLING_HOME/bin必须放在$PATH开头确保优先匹配。执行source ~/.zshrc后运行which gatling应返回/path/to/gatling-charts-highcharts-bundle-3.0.0/bin/gatling。Windows系统属性 → 高级 → 环境变量 → 系统变量 → Path → 新建C:\gatling\gatling-charts-highcharts-bundle-3.0.0\bin3.2gatling.sh启动流程深度解析为什么不能跳过当你执行gatling命令时实际触发的是bin/gatling.sh。这个脚本不到 200 行但每一步都不可省略JVM 版本探测调用java -version 21 | grep version | awk -F {print $2} | awk -F. {print $1}提取主版本号若 11则echo Java 11 required并退出Bundle 根目录定位GATLING_HOME$(cd $(dirname $0)/.. pwd)这是它唯一一次使用GATLING_HOME作为内部变量非环境变量Classpath 构建循环lib/*.jar拼接为CLASSPATH字符串显式包含lib/scala-library-2.12.17.jarJVM 参数注入硬编码-Dfile.encodingUTF-8 -Djava.awt.headlesstrue -XX:UseG1GC其中-XX:UseG1GC是为高吞吐压测场景优化不可删Main Class 启动exec java $JAVA_OPTS $GATLING_OPTS -cp $CLASSPATH io.gatling.app.Gatling $。关键点$GATLING_OPTS是唯一可由用户控制的 JVM 参数入口。如果你需要调大堆内存如-Xmx4g或添加 JMX 监控-Dcom.sun.management.jmxremote必须通过export GATLING_OPTS-Xmx4g设置而不是改脚本。3.3 验证启动脚本能正常加载不跑 simulation 也能测在完成 PATH 设置后不要急于写 simulation先执行gatling --help预期输出应为 Gatling 3.0.0 的 CLI 帮助文本包含Usage: gatling [options] -s, --simulation SIMULATION fully qualified name of the Simulation class to run -rf, --results-folder FOLDER folder where results will be stored ...若报错command not found: gatling检查 PATH 是否生效若报错Error: LinkageError occurred while loading main class io.gatling.app.Gatling大概率是lib/scala-library-2.12.17.jar缺失或版本错误若卡住无输出ps aux | grep java查看是否有僵尸 JVM 进程kill 后重试。4. 避坑Gatling 3.0.0 启动与编译阶段 5 大高频翻车点Gatling 3.0.0 的报错信息向来以“精准但晦涩”著称。它不会告诉你“你 Java 版本错了”只会抛一个java.lang.BootstrapMethodError它也不会说“你的 simulation 类没编译”而是静默跳过。以下是我在某高校性能实验室协助迁移时记录的真实踩坑日志按发生频率排序4.1 现象执行gatling后终端卡住 10 秒然后输出Exception in thread main java.lang.NoClassDefFoundError: scala/Function1原因lib/scala-library-2.12.17.jar被误删或被低版本如 2.11.12覆盖。Gatling 3.0.0 的io.gatling.core.scenario.Simulation类继承自scala.App而scala.Function1是 Scala 2.12 运行时的核心 trait2.11 中其签名不同。解决进入lib/目录rm scala-library*然后从官方 bundle 重新解压lib/scala-library-2.12.17.jar。切勿从 Maven 仓库单独下载该 jar —— 它必须与 bundle 中其他 jar 的 Scala 编译器版本严格一致。4.2 现象gatling --help正常但gatling -s foo.MySimulation报ClassNotFoundException: foo.MySimulation且user-files/simulations/下明明有该文件原因Gatling 3.0.0 默认不自动编译 Scala simulation 源码。它只加载user-files/target/scala-2.12/classes/下的.class文件。如果你直接把.scala文件丢进simulations/它会忽略。解决必须先执行gatling compile该命令会调用内置的 sbt编译user-files/simulations/**/*.scala并输出到user-files/target/。或者改用 Maven 方式见第 5 章由mvn compile控制编译流程。4.3 现象启动后控制台疯狂刷SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder最终OutOfMemoryError原因conf/logback.xml被修改或损坏导致 SLF4J 绑定失败日志系统退化为 NOP大量内存被未 flush 的 buffer 占用。Gatling 3.0.0 的默认logback.xml位于conf/它依赖lib/logback-classic-1.2.3.jar和lib/slf4j-api-1.7.25.jar。解决恢复conf/logback.xml为原始内容可从 GitHub 仓库 gatling/gatling 复制并确认lib/下两个 jar 存在且版本匹配slf4j-api-1.7.25.jarlogback-classic-1.2.3.jar。不要试图升级它们——Gatling 3.0.0 的日志模块与这两个版本强绑定。4.4 现象gatling compile报错error: bad symbolic reference to scala.Product原因user-files/simulations/下的 Scala 文件使用了 Scala 2.13 语法如val x: String ? default但 Gatling 3.0.0 的编译器是 sbt 1.2.8 Scala 2.12.17不支持。解决检查 simulation 文件中是否用了?、main、enum等 2.13 特性。全部改为 2.12 兼容写法如val x Option(default).getOrElse()。Gatling 3.0.0 的 DSL 文档明确标注所有 API 均基于 Scala 2.12。4.5 现象在 Windows 上执行gatling.bat报The system cannot find the path specified.且gatling.bat第 1 行echo off后立即退出原因Windows 路径中含空格如C:\Program Files\gatling\...而gatling.bat的set GATLING_HOME%~dp0..未加引号导致cd命令解析失败。解决将 Gatling 安装路径改为无空格如C:\gatling\或手动编辑gatling.bat在第 22 行左右找到cd /d %GATLING_HOME%改为cd /d %GATLING_HOME%。同理所有%GATLING_HOME%出现处都需加英文双引号。5. 使用 Maven 方式构建 simulation替代gatling compile的稳定方案虽然 Gatling bundle 自带gatling compile命令但它底层调用的是嵌入式 sbt对 Windows 路径、中文路径、多 module 项目支持极差。在某跨平台系统压测项目中我们最终统一迁移到 Maven 方式因为它能复用团队已有的 CI 流程、IDE 支持完善且pom.xml的依赖管理比 bundle 的lib/目录更透明。5.1 创建标准 Maven 结构与 bundle 无缝集成Gatling 3.0.0 完全兼容 Maven只需保证目录结构与 bundle 的user-files/对齐。在gatling-charts-highcharts-bundle-3.0.0/同级新建my-gatling-project/结构如下my-gatling-project/ ├── pom.xml ├── src/ │ └── test/ │ ├── resources/ │ │ └── logback-test.xml ← 测试专用日志配置 │ └── scala/ │ └── foo/ │ └── MySimulation.scala └── target/ ← Maven 编译输出Gatling 会自动识别注意src/test/scala/是 Maven Scala 插件约定路径Gatling 3.0.0 的gatling-maven-plugin会自动扫描此处。不要把 simulation 放在user-files/simulations/下——那是 bundle 自带编译模式的路径与 Maven 冲突。5.2pom.xml关键配置Gatling 3.0.0 专用以下pom.xml经实测通过重点在于scala-maven-plugin和gatling-maven-plugin的版本锁定?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion groupIdfoo/groupId artifactIdmy-gatling/artifactId version1.0-SNAPSHOT/version properties maven.compiler.source11/maven.compiler.source maven.compiler.target11/maven.compiler.target scala.version2.12.17/scala.version gatling.version3.0.0/gatling.version /properties dependencies dependency groupIdio.gatling.highcharts/groupId artifactIdgatling-charts-highcharts/artifactId version${gatling.version}/version scopetest/scope /dependency dependency groupIdio.gatling/groupId artifactIdgatling-test-framework/artifactId version${gatling.version}/version scopetest/scope /dependency /dependencies build plugins !-- Scala 编译插件必须指定 2.12.17 -- plugin groupIdnet.alchim31.maven/groupId artifactIdscala-maven-plugin/artifactId version4.3.0/version configuration scalaVersion${scala.version}/scalaVersion args arg-target:jvm-1.8/arg !-- 兼容 JVM 11 -- /args /configuration executions execution goals goalcompile/goal goaltestCompile/goal /goals /execution /executions /plugin !-- Gatling Maven 插件3.0.0 版本必须用 3.0.4 -- plugin groupIdio.gatling/groupId artifactIdgatling-maven-plugin/artifactId version3.0.4/version configuration runMultipleSimulationstrue/runMultipleSimulations includes includefoo.*/include /includes /configuration executions execution goals goalintegration-test/goal /goals /execution /executions /plugin /plugins /build /project关键参数说明scala.version2.12.17/scala.version必须与 bundle 中lib/scala-library-2.12.17.jar严格一致gatling.version3.0.0/gatling.versionGatling 核心版本pluginversion3.0.4/version/plugingatling-maven-plugin的 3.0.0 对应插件版本是 3.0.4官方文档未明说但 3.0.0 插件会报No plugin found for prefix gatlingarg-target:jvm-1.8/argScala 编译目标设为 JVM 1.8是为了兼容 Gatling 3.0.0 的字节码它自己就是-target:jvm-1.8编译的避免UnsupportedClassVersionError。5.3 用 Maven 启动压测绕过 bundle 的gatling.sh在my-gatling-project/目录下执行mvn gatling:testMaven 会自动编译src/test/scala/下所有 simulation将 class 文件输出到target/test-classes/启动 Gatling JVM并设置-cp包含target/test-classes和所有依赖 jar扫描target/test-classes/下的 simulation 类执行。提示若想指定单个 simulation用mvn gatling:test -Dgatling.simulationClassfoo.MySimulation。这比gatling -s更可靠因为 classpath 由 Maven 精确控制不受lib/目录污染影响。6. 验证 Gatling 3.0.0 真正跑通从第一个 HTTP simulation 到可交付报告装完不等于跑通。Gatling 3.0.0 的价值不在启动成功而在能否生成一份可解释、可归档、可对比的压测报告。下面用一个真实可复现的 minimal simulation带你走完从代码编写、编译、执行到报告验证的闭环。这个过程我每天至少做三遍它是我判断环境是否“真稳”的后悔药。6.1 编写一个零依赖的 HTTP simulationMyFirstSimulation.scala把以下代码保存为user-files/simulations/foo/MyFirstSimulation.scala如果用 Maven则放src/test/scala/foo/MyFirstSimulation.scalapackage foo import io.gatling.core.Predef._ import io.gatling.http.Predef._ import scala.concurrent.duration._ class MyFirstSimulation extends Simulation { val httpProtocol http .baseUrl(https://httpbin.org) // 公共测试服务无需认证 .acceptHeader(application/json) val scn scenario(Basic HttpBin Test) .exec(http(request_1) .get(/get) .check(status.is(200)) .check(jsonPath($.url).saveAs(responseUrl))) setUp( scn.inject(rampUsers(10) during (5 seconds)) ).protocols(httpProtocol) }这段代码做了四件事定义 HTTP 协议基础 URL 为https://httpbin.org一个稳定、免登录、返回 JSON 的公共 API创建一个名为Basic HttpBin Test的场景发送一个 GET 请求到/get检查 HTTP 状态码为 200并用jsonPath提取响应中的url字段存为 session 变量responseUrl设置注入策略5 秒内线性增加 10 个用户即每秒 2 个用户。注意这里不使用任何外部数据文件或 CSV排除 I/O 问题不启用任何高级特性如 feeder、checkBodyString聚焦核心链路。6.2 执行并观察实时日志确认 JVM 和 Gatling 内核工作正常如果是 bundle 方式先编译再运行gatling compile gatling -s foo.MyFirstSimulation如果是 Maven 方式mvn clean gatling:test -Dgatling.simulationClassfoo.MyFirstSimulation执行后你会看到类似这样的实时输出 2023-10-05 14:22:33 10s elapsed ---- Basic HttpBin Test ------------------------------------------------------ [########################################################################] 100% waiting: 0 / active: 10 / done:0 ---- Requests ---------------------------------------------------------------- Global (OK10 KO0 )关键指标解读waiting: 0 / active: 10 / done:0表示当前有 10 个用户正在活跃请求0 个等待0 个已完成——说明注入策略生效Global (OK10 KO0)10 个请求全部成功HTTP 200无超时、无连接拒绝、无断连。若此处出现KO10或active: 0卡住说明网络不通或httpbin.org临时不可用极少见可换为https://jsonplaceholder.typicode.com/posts/1测试。6.3 检查生成的 HTML 报告验证 Gatling 引擎与 Highcharts 渲染链路压测结束后Gatling 会自动在results/目录下生成时间戳命名的子目录例如results/myfirstsimulation-1696515753421/。进入该目录打开index.html。报告首页应包含Summary Table显示 Total Requests、Mean Response Time、95th percentile 等核心指标ChartsHighcharts 渲染的响应时间分布图、RPSRequests Per Second趋势图、状态码分布饼图Scenario Details点击Basic HttpBin Test能看到每个 request 的详细统计如request_1的 OK/KO 数、平均延迟。提示若打开index.html是白屏或报ReferenceError: Highcharts is not defined说明gatling-charts-highcharts-bundle-3.0.0中的lib/highcharts-6.2.0.js未被正确加载。检查results/xxx/index.html源码确认script src../lib/highcharts-6.2.0.js路径是否正确应为相对路径../lib/而非绝对路径。这是 Gatling 3.0.0 的一个已知 bug修复方法是手动复制bundle/lib/highcharts-6.2.0.js到results/xxx/lib/目录下。6.4 报告归档与自动化验证CI/CD 可落地的关键Gatling 3.0.0 的报告是纯静态 HTML/CSS/JS无后端依赖。这意味着你可以将results/xxx/整个目录压缩为report-$(date %Y%m%d-%H%M%S).zip上传至对象存储用grep -o OK[0-9]* results/xxx/index.html | head -1提取 OK 数写入监控指标用jq -r .statistics.summary.total.numberOfRequests results/xxx/stats.json解析 JSON 数据做阈值告警如numberOfRequests 10则失败。这是我从某图像处理 Demo 项目中学到的血泪经验永远不要相信“控制台输出 OK”就代表压测成功。必须验证stats.json中的numberOfRequests与注入用户数一致且allRequestsOK为true。因为 Gatling 3.0.0 在极端高并发下可能出现“请求发出但未收到响应”的 silent failure此时控制台仍显示 OK但stats.json里numberOfRequests会小于预期。从那以后我每次执行压测都强制走一遍# 等待压测结束 sleep 5 # 找到最新 results 目录 LATEST$(ls -td results/*/ | head -1) # 验证核心指标 if [[ $(jq -r .statistics.summary.allRequestsOK $LATEST/stats.json) ! true ]]; then echo ❌ 压测失败存在 KO 请求 exit 1 fi if [[ $(jq -r .statistics.summary.total.numberOfRequests $LATEST/stats.json) -lt 10 ]]; then echo ❌ 压测失败请求数不足 10 exit 1 fi echo ✅ 压测通过报告位于 $LATEST希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?
咨询建站