企业官网建设流程全解析

简介：Gatling 3.0.0 是一款面向现代 Web 应用的性能测试工具，适合开发者与测试工程师用来模拟高并发用户负载，验证系统在压力下的响应时间、吞吐量与资源利用率。其脚本基于 Scala 的 DSL 语法编写，可读性与可维护性较强，支持场景定义、执行速率设置、检查点与会话变量配置，并借助 Highcharts 生成交互式图表报告，直观呈现每秒请求数、平均响应时间与百分位分布。资源包共 114 个文件，以 97 个 jar 依赖库为主，辅以 6 个 scala 脚本、3 个 conf 配置、2 个 bat 与 2 个 sh 启动脚本，以及 csv 数据样例和 xml 等文件，压缩包约 57.17MB，解压后可直接运行录制与压测命令。目前已有 237 人学习下载，适合希望快速搭建性能测试环境、理解 Gatling 脚本结构与报告解读的读者参考使用。

1. 从一次压测环境翻车说起：gatling3.0.0 到底该怎么装

上周帮某团队排查一个接口压测问题，现象很典型：本地用 gatling3.0.0 跑得好好的脚本，换到另一台机器上直接起不来，报错指向 Scala 版本不匹配。折腾半天才发现，问题不在脚本，而在环境——JDK 版本、Scala 二进制版本、gatling 解压路径三者没对齐。gatling3.0.0 这个版本对运行环境比较挑剔，装不好就是各种NoClassDefFoundError、UnsupportedClassVersionError轮番上阵。这篇笔记按我实际部署的顺序，把 JDK 选型、gatling3.0.0 下载解压、目录结构、脚本目录配置、录制代理、报告生成一路写下来，中间穿插几个血泪踩坑点。适合刚接触性能测试 gatling3.0 的开发者，也适合想把压测环境从旧版本迁过来的熟手。

2. 装前先把环境列清：JDK 与 Scala 的版本对齐

gatling3.0.0 是 2016 年底发布的版本，它的运行依赖和现在主流的 gatling 3.10+ 差别不小。很多人栽在第一步：拿 JDK 17 去跑 gatling3.0.0，启动直接报UnsupportedClassVersionError。这一章把版本矩阵、下载渠道、解压布局讲透，后面装起来才不返工。

2.1 版本矩阵：JDK 8 是硬门槛

gatling3.0.0 编译目标是 Java 8，官方文档明确要求 JDK 8。我实测过 JDK 11 能启动但部分 Scala 反射调用会出警告，JDK 17 直接拒绝。所以环境基线定死：

这里有个反直觉的点：gatling3.0.0 的完整包（bundle）里已经带了 Scala 编译器和运行时，你不需要在系统里单独scala -version能跑。很多人看到脚本是.scala后缀就以为要先装 Scala，结果装了个 2.13 的 Scala 反而和内置的 2.12 冲突。常见做法是：只用 bundle 包，系统里不装 Scala，避免版本打架。

JDK 的安装按发行版走，以常见的 OpenJDK 8 为例：

# 确认当前 JDK 版本，输出必须是 1.8.x java -version # 如果系统里有多版本，用 alternatives 切换（Debian/Ubuntu 系） sudo update-alternatives --config java sudo update-alternatives --config javac # 验证 JAVA_HOME 指向 JDK 8 而非 JRE echo $JAVA_HOME

java -version输出里如果出现1.8.0_xxx才算过关；JAVA_HOME必须指向 JDK 根目录（含bin/javac），指向 JRE 目录会导致 gatling 编译脚本时找不到编译器。这一步别偷懒，后面所有报错排查都从这两个命令的输出开始。

2.2 下载与解压：认准 bundle 包，别下错 zip

gatling3.0.0 的发布包分两种：一种是gatling-charts-highcharts-bundle-3.0.0.zip（完整包，含脚本模板、依赖、启动脚本），另一种是 Maven 依赖形式。做独立压测环境，直接下 bundle 包最省事。下载后解压到一个不带空格、不带中文的路径，我一般放/opt/gatling：

# 解压到 /opt 下 sudo unzip gatling-charts-highcharts-bundle-3.0.0.zip -d /opt/ # 重命名，去掉冗长的版本后缀，方便脚本引用 sudo mv /opt/gatling-charts-highcharts-bundle-3.0.0 /opt/gatling # 看下目录结构 ls /opt/gatling

解压后你会看到bin/、lib/、conf/、user-files/、results/这几个目录。bin/里是gatling.sh和recorder.sh两个启动脚本；lib/是全部 jar 依赖；conf/放gatling.conf和日志配置；user-files/是你写脚本和放数据文件的地方；results/是压测报告输出目录。路径里带空格是经典翻车点——gatling.sh内部用$0推导路径，空格会把参数截断，报No such file or directory。所以/opt/gatling这种干净路径最稳。

2.3 目录权限与执行位

解压出来的gatling.sh默认可能没有执行权限，直接./gatling.sh会报Permission denied。另外如果压测机是多用户共用，results/目录的写权限要提前确认：

# 给启动脚本加执行位 chmod +x /opt/gatling/bin/*.sh # 确认当前用户对 results 和 user-files 有写权限 ls -ld /opt/gatling/results /opt/gatling/user-files # 如果当前用户不是 root，把目录属主改过来（示例用户为 deploy） sudo chown -R deploy:deploy /opt/gatling

chmod +x只解决执行位，属主问题不解决的话，压测跑完写报告时会报Permission denied，而且这个报错出现在压测结束阶段，很容易被误判成脚本问题。我一般装完就先touch /opt/gatling/results/test.txt试一下写权限，能写再往下走。

3. 配置 gatling3.0.0：从 gatling.conf 到脚本目录

环境就位后，真正决定能不能跑通的是配置。gatling3.0.0 的配置集中在conf/gatling.conf，脚本放在user-files/simulations/，数据文件放user-files/resources/。这一章把关键配置项、脚本目录约定、录制器参数逐个拆开，每个改动都给出可抄的配置片段。

3.1 gatling.conf 里必须改的几项

conf/gatling.conf是 HOCON 格式，层级用缩进表达。默认配置能跑，但压测机和生产环境不同，有几项建议按实际情况调：

gatling { core { # 压测结果输出目录，默认在 gatling 根目录下 resultsDirectory = "results" # 编码，中文环境建议显式指定 encoding = "utf-8" # 是否在控制台输出每个请求的详情，调试时开，正式压测关 mute = false } http { # 连接超时，单位毫秒 connectTimeout = 10000 # 请求超时 requestTimeout = 60000 # 是否跟随重定向 followRedirect = true } data { # 报告里是否写请求/响应体，数据量大时关掉省磁盘 writers = [] } }

resultsDirectory改成绝对路径（如/data/gatling-results）在容器化部署时更稳，避免工作目录变化导致报告找不到。mute = true会关掉控制台逐请求输出，高并发下能明显减少 IO 开销，但调试阶段别开，否则你看不到失败请求的细节。requestTimeout默认 60 秒，压测慢接口时要往上调，否则大量请求被判定超时，报告里的错误率会虚高。

改完配置不用重启任何服务，gatling 每次启动都会重新读conf/gatling.conf。但要注意：如果你用-sf参数指定了别的配置目录，读的就是那份，别改错文件。

3.2 脚本目录约定与第一个 Simulation

gatling3.0.0 默认从user-files/simulations/加载脚本，文件名和类名要对应。新建一个最小可跑的脚本验证环境：

// 文件路径：user-files/simulations/BasicSimulation.scala import io.gatling.core.Predef._ import io.gatling.http.Predef._ import scala.concurrent.duration._ class BasicSimulation extends Simulation { // 压测目标地址，换成你自己的被测服务 val httpConf = http.baseUrl("http://127.0.0.1:8080") // 场景定义：1 个虚拟用户，发 1 次请求 val scn = scenario("BasicCheck") .exec(http("request_1").get("/health")) // 注入策略：atOnceUsers 表示一次性拉起指定数量用户 setUp( scn.inject(atOnceUsers(1)) ).protocols(httpConf) }

这段脚本的作用是「冒烟验证」：只发一个请求，确认 gatling 能编译脚本、能发 HTTP、能出报告。baseUrl指向被测服务根地址，/health换成任何能返回 200 的路径即可。atOnceUsers(1)是最简单的注入模型，正式压测再换成rampUsers或constantUsersPerSec。脚本类名BasicSimulation必须和文件名一致，否则启动时列表里看不到它。

启动命令：

cd /opt/gatling ./bin/gatling.sh

启动后终端会列出user-files/simulations/下所有 Simulation 让你选序号。选完回车，压测跑完会在results/下生成一个带时间戳的目录，里面index.html就是报告。第一次跑建议就选这个BasicSimulation，能出报告说明环境通了。

3.3 录制器 recorder.sh 的参数取舍

gatling3.0.0 自带 HTTP 录制器，能把浏览器操作转成 Scala 脚本。启动方式：

./bin/recorder.sh

图形界面里要填几个关键参数：监听端口（默认 8000）、目标地址、输出包名和类名。这里有个容易忽略的点——录制器本质是个本地代理，浏览器要手动把 HTTP 代理指到127.0.0.1:8000，否则录不到任何请求。录完点保存，脚本会落到user-files/simulations/下你指定的包路径里。

参数取舍上，--mode选HTTP还是HTTPS取决于被测站点；如果站点有证书问题，录制阶段会报 SSL 握手失败，常见做法是先在浏览器里信任证书再录。录制出来的脚本通常带一堆静态资源请求，正式压测前要手动删掉图片、CSS 这类无关请求，只留业务接口，否则压测数字会被静态资源稀释。

3.4 用 Maven 方式跑时的依赖配置

如果团队要求把压测脚本纳入工程管理，不走 bundle 包而是 Maven 依赖，pom.xml里要锁死版本：

<dependencies> <dependency> <groupId>io.gatling.highcharts</groupId> <artifactId>gatling-charts-highcharts</artifactId> <version>3.0.0</version> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>io.gatling</groupId> <artifactId>gatling-maven-plugin</artifactId> <version>3.0.0</version> </plugin> </plugins> </build>

Maven 方式的好处是依赖版本可复现，坏处是插件版本必须和 gatling 主版本严格对应，3.0.0的插件配3.0.0的库，混用会报NoSuchMethodError。跑的时候用mvn gatling:test，脚本放src/test/scala/下。这种方式适合 CI 里跑回归压测，但首次搭建比 bundle 包多花时间，新手建议先用 bundle 包跑通再迁。

4. 避坑与排查：gatling3.0.0 装完起不来的五种情况

这一章是我在几台机器上装 gatling3.0.0 攒下来的排查清单，每条都按「现象 → 原因 → 解决」写。装完起不来别急着重装，先对着这五条过一遍，八成能定位。

4.1 现象：启动报 UnsupportedClassVersionError

终端输出类似Unsupported major.minor version 52.0或class file version 61.0。原因很直接：当前java不是 JDK 8，可能是 11 或 17。解决：java -version确认版本，用update-alternatives或改JAVA_HOME切回 1.8，再echo $JAVA_HOME确认指向 JDK 而非 JRE。切完记得新开终端，环境变量不会自动刷新到已开的会话。

4.2 现象：脚本列表为空，选不到 Simulation

./bin/gatling.sh启动后提示There are no simulations available。原因通常是脚本没放对目录，或者文件扩展名不是.scala，或者类名和文件名不一致。解决：确认文件在user-files/simulations/下（子目录也可以，但包名要对应），ls看一眼扩展名，再检查class XxxSimulation和文件名是否完全一致。大小写敏感的系统上basicSimulation.scala和BasicSimulation不匹配也会导致加载失败。

4.3 现象：压测跑完 results 目录为空

控制台显示压测完成，但results/下没有新目录。原因是results/写权限不足，或者gatling.conf里resultsDirectory被改到了一个不存在的路径。解决：ls -ld results看属主，touch results/test.txt测写权限，权限不对就chown；配置被改过就改回相对路径results或确认绝对路径存在。这个坑最阴，因为报错发生在压测结束，容易被当成「压测没跑」。

4.4 现象：录制器录不到请求

recorder.sh界面正常，浏览器操作也做了，但请求列表是空的。原因是浏览器没设代理，或者代理设了但端口和录制器监听端口不一致。解决：浏览器网络设置里把 HTTP 代理指到127.0.0.1:8000（和录制器界面里的端口一致），HTTPS 站点要确认录制器模式选对。另外有些浏览器插件会绕过系统代理，录制前先禁用。

4.5 现象：高并发下报 OutOfMemoryError

压测用户数拉高后 JVM 抛java.lang.OutOfMemoryError: Java heap space。原因是默认堆太小，gatling 每个虚拟用户都占内存。解决：改bin/gatling.sh里的JAVA_OPTS，把-Xmx调大，比如-Xmx4g，同时-Xms设成和-Xmx一样避免频繁扩容。压测机内存有限时，宁可减少并发用户数，也别硬扛 OOM，否则报告数据不可信。

提示：这五条里前三条是安装阶段的高频问题，后两条偏运行阶段。装完先跑BasicSimulation冒烟，能出报告再上正式脚本，能省掉大量「到底是环境问题还是脚本问题」的扯皮。

5. 装完怎么验证跑通：三步确认法与报告核对

环境装完、配置改完，最后一步是确认「真的跑通了」，而不是「看起来没报错」。我一般走三步：先验 JDK 和目录，再跑冒烟脚本看报告，最后核对报告里的关键指标是否合理。三步都过，这套 gatling3.0.0 环境才算交付。

5.1 第一步：环境自检三连

# 1. JDK 必须是 1.8 java -version 2>&1 | grep '1.8' # 2. gatling 启动脚本可执行 test -x /opt/gatling/bin/gatling.sh && echo "gatling.sh OK" # 3. 配置和脚本目录存在且可写 test -w /opt/gatling/results && echo "results writable" ls /opt/gatling/user-files/simulations/

三条命令的输出分别是版本行、gatling.sh OK、results writable和脚本文件列表。任何一条不符合，回到对应章节处理。这一步的意义是把「环境问题」和「脚本问题」提前隔离开，后面出问题就不用再怀疑基础环境。

5.2 第二步：冒烟脚本跑出报告

用第 3 章的BasicSimulation跑一次，终端最后会打印类似：

Simulation BasicSimulation completed in 3 seconds Parsing log file(s)... Generating reports... Reports generated in 0s. Please open the following file: /opt/gatling/results/basicsimulation-20240101120000000/index.html

看到Reports generated和index.html路径，说明编译、发请求、写报告整条链路通了。打开index.html，重点看三个数字：总请求数是否为 1、成功率和响应时间是否正常。如果请求数是 0，说明脚本里的exec没生效；如果成功率不是 100%，先查被测服务是否真的在/health返回 200。

5.3 第三步：报告指标核对表

冒烟通过后，用正式脚本跑一轮小并发，对照下表核对报告，确认数据可信：

这张表的作用是防止「报告出来了但数据是错的」。我见过压测机自己 CPU 打满导致响应时间虚高的案例，报告看着像被测服务慢，实际是压测端瓶颈。核对时如果 KO 率异常高但被测服务日志正常，优先怀疑压测机资源。

5.4 一个容易忽略的收尾动作

每次压测前清空或归档results/旧目录。gatling3.0.0 不会自动清理历史报告，跑多了磁盘会被撑满，某次压测突然报写盘失败，排查半天才发现是磁盘满了。我现在的习惯是压测脚本外面套一层rm -rf results/*或者按日期归档，跑之前先df -h看一眼剩余空间。

从那以后我每次装完 gatling3.0.0，都强制走一遍「环境自检三连 + 冒烟脚本 + 报告核对」这套流程，不跳步。环境这东西，装的时候多花十分钟确认，比出问题后翻两小时日志划算得多。希望帮到你。

本文还有配套的精品资源，点击获取