1. 项目概述与核心价值

最近在搞一个SpringBoot项目的上线前准备，团队里几个后端兄弟代码写得飞起，功能测试也基本跑通了，但一到性能这块，心里总有点没底。线上环境和本地开发机完全是两码事，你永远不知道当几百上千个用户同时点开某个报表页面，或者集中提交一个表单时，你的服务会不会直接“躺平”。所以，在正式发布前，做一轮靠谱的压力测试，就跟出门前看天气预报一样，属于基本操作。

这次我选用的工具是Apache JMeter 5.6.3，一个老牌且强大的开源性能测试工具。为什么是它？首先，它足够成熟，社区活跃，遇到问题基本都能找到解决方案；其次，它对HTTP/HTTPS协议的支持非常友好，而我们的SpringBoot应用主要就是提供RESTful API，简直是绝配；再者，它的图形化界面和丰富的监听器，能让我们直观地看到吞吐量、响应时间、错误率等关键指标，数据说话，比拍脑袋靠谱多了。

这篇文章，我会从一个实际项目出发，带你走一遍用JMeter 5.6.3对SpringBoot应用进行压力测试的完整流程。更重要的是，我会把我自己在这个过程中踩过的、以及见过别人踩过的五个典型“坑”详细拆解出来。这些坑，有些是关于JMeter工具本身配置的，有些是关于测试脚本设计的，还有些是关于结果分析和环境认知的。我希望你看完不仅能学会“怎么做”，更能明白“为什么这么做”，以及“怎么避免掉坑里”。无论你是刚接触性能测试的新手，还是想优化现有测试流程的老鸟，相信都能从中找到一些实用的参考。

2. 测试环境与目标定义

在动手之前，盲目地开压是没有意义的。我们必须先明确测试的目标和边界，准备好合适的环境，这样得到的数据才有分析的价值。

2.1 明确测试目标与场景

压力测试不是漫无目的地“打流量”，我们需要针对核心业务场景。以我手头这个电商后台管理系统为例，我重点关注以下几个场景：

  1. 用户登录鉴权 ：这是所有请求的入口，它的性能直接影响用户体验。我模拟用户携带用户名密码调用登录接口，获取Token。
  2. 商品列表查询 ：这是一个高频的读操作，通常涉及数据库查询和可能的缓存。我测试带分页参数查询商品列表的接口。
  3. 订单创建 ：这是一个写操作，涉及业务逻辑校验、库存扣减、订单数据入库等多个步骤，是典型的复杂事务场景。
  4. 数据报表导出 ：这是一个CPU和内存密集型操作，涉及大量数据查询、内存计算和Excel文件生成，容易引发内存溢出（OOM）。

对于每个场景，我需要定义明确的性能指标（SLA）：

  • 响应时间（Response Time） ：95%的请求响应时间应在200ms以内，99%的请求应在500ms以内（针对查询类接口）。写操作可适当放宽，但不应超过1秒。
  • 吞吐量（Throughput） ：系统在单位时间内（每秒）能成功处理的请求数。例如，商品列表查询的吞吐量目标为每秒1000次请求（QPS）。
  • 错误率（Error Rate） ：在持续压力下，HTTP状态码非2xx/3xx的请求比例应低于0.1%。
  • 资源利用率 ：在目标压力下，应用服务器的CPU使用率应低于70%，内存使用应平稳，无持续增长（内存泄漏）。

2.2 搭建隔离的测试环境

绝对不要在开发环境或生产环境直接进行压力测试！ 这是铁律。我们需要一个尽可能贴近生产环境的独立测试环境。

  1. 应用部署 ：我将SpringBoot应用打包成JAR，部署在一台独立的Linux服务器上。配置（JVM参数、数据库连接池等）与生产环境保持一致。例如，生产环境用4核8G，测试环境也用相同规格的云主机或虚拟机。
  2. 中间件与数据库 ：使用独立的Redis缓存实例和MySQL数据库实例。数据库中的数据量需要有一定规模，不能只用几条测试数据。我通过脚本向测试库灌入了百万级别的商品数据和用户数据，以模拟真实的数据查询压力。
  3. 压力机（JMeter运行机） ：这是运行JMeter脚本的机器。 一个常见的误区是忽略了压力机本身的性能 。如果压力机性能太差，它可能无法产生足够高的并发，或者自身先成为瓶颈，导致测试结果失真。我的经验是，压力机最好与应用服务器分开，并且其硬件配置（特别是CPU和网络）不能太弱。本次测试，我使用了一台4核8G的Linux机器作为压力机。

注意 ：确保网络通畅，压力机与测试应用服务器之间的网络延迟（Ping值）要低且稳定。跨机房或公网压测会引入巨大的网络不确定性。

2.3 JMeter 5.6.3 基础配置与优化

从官网下载JMeter 5.6.3，解压即可用。但默认配置是针对一般情况的，进行高并发压测前，必须调整JMeter自身的配置，否则它可能先于你的应用崩溃。

  1. 调整JVM参数 ：编辑 jmeter/bin 目录下的 jmeter （Linux）或 jmeter.bat （Windows）文件，找到JVM参数设置部分。

    # 找到类似 HEAP 的设置，默认可能只有 -Xms1g -Xmx1g
# 根据你的压力机内存调整，建议设置为可用内存的70%-80%，但不要超过物理内存
HEAP="-Xms4g -Xmx4g -XX:MaxMetaspaceSize=512m"

    将堆内存（-Xms, -Xmx）设置得足够大，以避免JMeter在压测过程中因内存不足而频繁GC甚至OOM。我的压力机有8G内存，我分配了4G给JMeter。

  2. 禁用图形界面（GUI）进行压测 ：JMeter的GUI模式非常耗资源，只用于脚本编写和调试。 正式压测一定要在非GUI（命令行）模式下运行 。

    jmeter -n -t your_test_plan.jmx -l result.jtl -e -o ./report
    • -n : 非GUI模式。
    • -t : 指定测试计划（.jmx文件）。
    • -l : 指定结果文件（.jtl）。
    • -e -o : 测试结束后生成HTML报告到指定目录。

  3. 修改 jmeter.properties ：

    • jmeter.save.saveservice.thread_counts=true ：在结果文件中保存活跃线程数，便于分析。
    • 根据并发数调整 jmeter.engine.threads.max （默认100），但通常命令行模式不受此限制，主要关注脚本设计。

3. 测试脚本设计与核心元件详解

一个结构清晰、配置合理的测试脚本是压测成功的基础。JMeter的元件（Sampler, Listener, Timer, Assertion等）就像积木，需要合理搭建。

3.1 线程组：定义并发模型

线程组（Thread Group）是压测的起点，它定义了虚拟用户（线程）的行为模式。我常用的是“线程组”和“Stepping Thread Group”（通过插件安装，更灵活）。

  • 普通线程组 ：设置线程数（并发用户数）、循环次数、启动时间（Ramp-Up Period）。例如，100个线程在10秒内启动完毕，然后每个线程循环执行采样器，直到循环结束。
  • Stepping Thread Group ：更适合做“爬坡”测试。我可以设置：开始时0个用户，每30秒增加50个用户，直到达到200个用户，然后持续压测5分钟，最后每30秒减少50个用户。这种模式可以观察系统在不同压力阶梯下的表现，更容易找到性能拐点。

踩坑记录一：Ramp-Up Period 理解错误

  • 现象 ：设置了100个线程，Ramp-Up时间为0，期望瞬间产生100并发。结果发现请求是瞬间发起了，但JMeter内部线程初始化、脚本解析需要时间，实际并未真正实现“同时”。
  • 原因与解决 ：Ramp-Up=0并不意味着所有线程绝对同时启动。对于要求绝对并发的场景（如秒杀），更好的方法是使用“同步定时器（Synchronizing Timer）”。在关键请求前放置一个同步定时器，设置模拟用户组的数量（如100），这样JMeter会阻塞线程，直到凑够指定数量的线程，然后同时释放，发起请求，这才是真正的“并发”。

3.2 采样器与逻辑控制器

采样器（Sampler）用来发送请求。对于SpringBoot API，主要使用 HTTP请求 采样器。

  1. 配置HTTP请求 ：

    • 协议 ： http 或 https 。
    • 服务器名称或IP ：填写测试环境的服务器地址。
    • 端口号 ：应用端口，如 8080 。
    • 方法 ：GET、POST、PUT、DELETE等，与API定义一致。
    • 路径 ：API的路径，如 /api/v1/login 。
    • 参数 ：对于GET请求，在“参数”选项卡中添加。对于POST请求，根据接口要求，在“消息体数据”中填写JSON格式的请求体，并在“头信息”中添加 Content-Type: application/json 。

  2. 使用逻辑控制器 ：

    • 仅一次控制器（Once Only Controller） ：把登录请求放在这里面，确保每个虚拟用户只登录一次，获取Token，后续请求复用这个Token。这符合真实用户会话场景。
    • 循环控制器（Loop Controller） ：可以控制某个业务操作（如查询商品）循环执行多次。
    • 事务控制器（Transaction Controller） ：可以把登录、查询、下单等多个步骤组合成一个事务，JMeter会统计这个事务整体的响应时间，这对于衡量一个完整业务流程的性能非常有用。

3.3 参数化与关联

真实的压测请求不能总是相同的数据，否则缓存命中率会出奇的高，测试结果会过于乐观。

  1. 参数化（使用CSV数据集） ：

    • 准备CSV文件 ：创建一个 users.csv 文件，包含 username,password 两列，存储大量测试账号。
    • 添加CSV数据文件设置 ：在线程组下添加该元件，指定文件路径、变量名（如 USER , PWD ）。
    • 引用变量 ：在HTTP请求中，使用 ${USER} 和 ${PWD} 作为用户名和密码。JMeter会按顺序或随机读取文件中的记录，分配给不同的线程，实现用户参数化。对于商品ID等，也可以采用类似方式。

  2. 关联（正则表达式提取器或JSON提取器） ：

    • 问题 ：登录后，服务端返回一个Token（如 {"token": "eyJhbGciOiJ..."} ），后续的API请求需要在Header中携带这个Token（如 Authorization: Bearer eyJhbGciOiJ... ）。
    • 解决 ：在登录请求下，添加一个 JSON提取器 （如果返回是JSON）。设置变量名（如 access_token ），JSON路径表达式（如 $.token ）。然后，在后续的请求中，添加一个 HTTP信息头管理器 ，添加一条头信息： Authorization ，值为 Bearer ${access_token} 。

踩坑记录二：参数化数据量不足导致线程阻塞

  • 现象 ：压测运行一段时间后，吞吐量突然降为0，但线程还在运行。查看日志发现大量错误：“EOFException: Unexpected EOF read on the socket”。
  • 原因与解决 ：CSV文件中只准备了100条用户数据，但压测使用了200个线程，且循环次数设为“永远”。当100个线程用完了CSV数据后，后续线程读取不到数据，导致请求构建失败。 务必确保参数化数据量（CSV行数）大于等于线程数 。或者，将CSV数据文件设置中的“遇到文件结束符再次循环？”设为 True ，并设置“遇到文件结束符停止线程？”为 False ，让数据循环使用。

3.4 定时器与断言

  1. 定时器（Timer） ：用来控制请求之间的等待时间，模拟用户思考、操作间隔。不加定时器，线程会以最快速度循环发送请求，这属于“极限压测”，常用于探知系统绝对瓶颈。但为了模拟更真实的场景，通常会添加 固定定时器（Constant Timer） 或 高斯随机定时器（Gaussian Random Timer） ，比如设置一个300毫秒的平均等待时间。
  2. 断言（Assertion） ：用于验证服务器返回的响应是否符合预期。常用的有 响应断言 ，可以检查响应文本中是否包含某个关键字，或者检查JSON路径对应的值。例如，对登录接口断言响应代码为200，且响应文本包含 "success":true 。断言失败，该次请求会被记为失败。 合理使用断言是确保测试业务正确性的关键 ，否则你可能压测了半天，结果全是错误的请求，数据毫无意义。

4. 测试执行与监控

脚本设计好后，就可以开始执行压测了。但执行不是点一下启动就完事，我们需要边压边看，监控系统和应用的状态。

4.1 执行策略：阶梯加压与稳定性测试

我通常采用混合策略：

  1. 阶梯加压测试 ：使用Stepping Thread Group，从低并发开始，逐步增加（如50->100->150->200），每个阶梯持续5-10分钟。观察每个阶梯下的响应时间和吞吐量变化。当响应时间开始非线性增长或错误率飙升时，就找到了系统的性能拐点。
  2. 稳定性测试（耐力测试） ：在预估的最大并发用户数下（例如拐点并发数的80%），持续压测30分钟到数小时。目的是检查系统在长时间压力下，是否存在内存泄漏、资源耗尽（如数据库连接池）、响应时间逐渐变长等问题。

4.2 系统与应用层监控

光看JMeter的结果是不够的，必须结合服务器和应用的监控数据，才能进行根因分析。

  1. 服务器资源监控 ：

    • CPU ：使用 top 或 htop 命令，观察应用进程（Java）的CPU使用率。如果持续接近100%，可能是计算逻辑存在瓶颈。
    • 内存 ：使用 jstat -gcutil <pid> 1000 或可视化工具，观察JVM堆内存各区域（Eden, Survivor, Old Gen）的使用和GC情况。频繁的Full GC会导致应用暂停（Stop-The-World），响应时间毛刺。
    • 磁盘I/O ：使用 iostat -x 1 ，关注 %util （利用率）和 await （平均等待时间）。如果磁盘利用率持续很高，可能是日志写入过频或数据库操作密集。
    • 网络 ：使用 sar -n DEV 1 ，观察网络吞吐量是否达到瓶颈。

  2. 应用层监控 ：

    • Spring Boot Actuator ：这是SpringBoot自带的监控神器。在项目中引入 spring-boot-starter-actuator 依赖，并暴露 metrics 和 health 端点（注意安全配置）。通过 /actuator/metrics 可以查看JVM内存、线程池、HTTP请求等大量指标。
    • Micrometer + Prometheus/Grafana ：对于更专业的监控，可以集成Micrometer，将指标导出到Prometheus，再用Grafana做可视化看板。这样可以实时看到QPS、响应时间分布（直方图）、错误率等，与JMeter数据相互印证。
    • 数据库监控 ：监控测试数据库的活跃连接数、慢查询日志、锁等待情况。很多时候，应用层的瓶颈根源在数据库。

踩坑记录三：只压接口，不监控数据库

  • 现象 ：JMeter报告显示响应时间变长，错误率升高。应用服务器CPU和内存看起来都还好。
  • 原因与解决 ：登录数据库一看，发现大量慢查询，连接池中的连接全部处于“Sleep”状态，实际上是在等待数据库查询结果。原因是压测脚本频繁查询的某些字段没有加索引。 压测时，必须同步监控数据库 。使用 SHOW PROCESSLIST; 或数据库的监控工具，及时发现慢SQL并优化（加索引、优化查询语句）。

5. 结果分析与报告解读

压测完成后，JMeter会生成 .jtl 结果文件。使用 -e -o 参数可以生成一个直观的HTML报告。但看报告不能只看平均值，必须深入细节。

5.1 关键指标解读

打开HTML报告，重点关注：

  1. APDEX (Application Performance Index) ：性能满意度指数。它根据设定的阈值（T，通常是目标响应时间），将请求分为满意（<T）、可容忍（T ~ 4T）和失望（>4T）三类。Apdex分数越接近1越好。这是一个综合性的用户体验指标。
  2. 响应时间（Response Times） ：
    • 平均值 ：参考意义有限，容易被极端值拉偏。
    • 中位数 ：50%的请求响应时间低于此值，更能代表“典型”体验。
    • 90%/95%/99%分位（Percentile） ：这是黄金指标。例如， p95=250ms 表示95%的请求响应时间在250ms以内。我们通常更关注90%或95%分位值，因为它能反映绝大多数用户的体验，并暴露长尾问题。
  3. 吞吐量（Throughput） ：单位时间内的请求数。观察其随着并发数增加的变化曲线。理想情况下，吞吐量应随着并发增加而上升，达到某个点后趋于平稳或下降（系统饱和）。
  4. 错误率（Error %） ：必须低于既定目标（如0.1%）。要点击查看具体是哪些错误，是4xx（客户端错误，如参数不对、Token过期）还是5xx（服务器错误，如超时、内部异常）。
  5. 活动线程数（Active Threads Over Time）图表 ：确认实际的并发压力曲线是否符合脚本设定（如阶梯上升）。

5.2 图表关联分析

将不同的图表关联起来看，才能发现问题：

  • 响应时间 VS 活动线程数 ：当并发线程数增加时，响应时间是否平稳？如果响应时间曲线随着线程数增加而急剧上升，说明系统处理能力达到瓶颈。
  • 吞吐量 VS 活动线程数 ：吞吐量是否随着线程数增加而线性增长？在某个点之后是否不再增长甚至下降？那个点就是系统的最佳并发点，超过之后，系统忙于线程上下文切换和资源竞争，效率反而降低。
  • 响应时间分布（Response Time Percentiles） ：观察各分位线是否平稳。如果p99线突然飙升，而p50线平稳，说明存在一些慢请求，需要排查是否是某些特定操作（如导出报表）或某些数据（如查询某个大商户的数据）导致的。

踩坑记录四：盲目相信“平均响应时间”

  • 现象 ：报告显示平均响应时间为120ms，看起来很不错。但业务反馈时有用户抱怨卡顿。
  • 原因与解决 ：查看分位图，发现p99响应时间高达2s！这意味着有1%的请求非常慢，而这些慢请求拉高了部分用户的体验。平均值掩盖了长尾问题。 性能优化，很大程度上是在优化那1%甚至0.1%的慢请求 。必须重点关注p90, p95, p99等分位值。

5.3 生成与归档专业报告

HTML报告虽然直观，但有时需要更简洁的结论。我会从报告中提取关键数据，整理成如下表格，附在测试总结中：

测试场景 并发用户数 持续时间 总请求数 错误率 平均响应时间(ms) p95响应时间(ms) 吞吐量(QPS) 服务器CPU均值 结论
用户登录 100 5min 30000 0% 45 80 100 35% 达标
商品查询 200 5min 120000 0% 60 150 400 55% 达标
订单创建 50 5min 15000 0.05% 180 450 50 60% 基本达标，需优化慢请求
报表导出 10 5min 300 5% 3000 8000 1 85% 不达标 ，需重构

6. 典型问题排查与性能优化建议

根据压测结果，我们通常会遇到以下几类问题。这里结合我的踩坑经验，给出排查思路和优化方向。

6.1 高错误率（特别是5xx）

  • 问题现象 ：错误率超过预期，大量500 Internal Server Error或503 Service Unavailable。
  • 排查步骤 ：
    1. 查看应用日志 ：这是第一步。SpringBoot应用的日志中通常会记录未捕获的异常堆栈信息。可能是空指针、数据库连接超时、第三方服务调用失败等。
    2. 检查资源限制 ：
      • 数据库连接池 ：检查连接池配置（如HikariCP的 maximumPoolSize ）。如果连接池耗尽，新的请求获取不到连接，就会等待超时或抛出异常。在压测中适当调大连接池，并监控活跃连接数。
      • 线程池 ：SpringBoot内嵌的Tomcat有工作线程池（ server.tomcat.max-threads ），如果并发请求数超过此值，请求会被堆积在队列中，队列满后则会拒绝连接。根据压测结果调整此值。
      • 操作系统限制 ：检查压力机和服务器的文件描述符限制（ ulimit -n ）和端口范围。高并发下，如果端口耗尽，也会导致连接错误。
    3. 检查依赖服务 ：如果你的应用调用了其他微服务、Redis或MQ，确保它们也能承受相应的压力。一个下游服务的崩溃会导致上游服务大面积报错。

6.2 响应时间过长或随并发增长过快

  • 问题现象 ：p95响应时间远超目标，且随着并发数增加，响应时间曲线陡增。
  • 排查与优化 ：
    1. 数据库层面 ：
      • 慢SQL ：分析数据库慢查询日志。对高频查询的WHERE条件字段添加索引。避免 SELECT * ，只取需要的字段。
      • 锁竞争 ：检查是否存在行锁、表锁等待。优化事务粒度，避免长事务。对于读多写少的场景，考虑使用读写分离。
    2. 应用代码层面 ：
      • 算法复杂度 ：检查是否存在循环嵌套过深、重复计算等问题。使用Profiler工具（如Arthas、Async-Profiler）找出CPU热点方法。
      • 同步锁 ：检查是否在高并发路径上使用了粗粒度的锁（如 synchronized 方法）。考虑改用并发容器（ ConcurrentHashMap ）、乐观锁或细化锁粒度。
      • 远程调用 ：检查对Redis、其他HTTP服务的调用是否同步且未设置超时。为所有外部调用设置合理的连接超时和读取超时，并考虑异步化或批量处理。
    3. JVM层面 ：
      • GC停顿 ：如果发现响应时间曲线有规律的“毛刺”，可能是Full GC导致的。分析GC日志（启用 -Xlog:gc* ），优化JVM参数，如调整堆大小、选择合适的GC器（如G1）。
      • 内存泄漏 ：在稳定性测试中，观察老年代（Old Gen）内存使用是否持续增长而不被回收。使用 jmap 或内存分析工具（Eclipse MAT）抓取堆转储文件进行分析。

6.3 吞吐量上不去，CPU/内存使用率低

  • 问题现象 ：增加并发用户数，但吞吐量不再增长，而服务器CPU和内存使用率并不高。
  • 排查与优化 ：
    1. 外部瓶颈 ：瓶颈可能不在应用服务器。检查测试环境网络带宽是否已满。检查数据库的CPU和IO是否已达上限。使用 ping 和 traceroute 检查网络延迟和稳定性。
    2. 同步等待 ：应用可能大量时间在等待外部响应，处于IO等待状态，所以CPU空闲。检查是否有大量的同步HTTP调用、数据库查询等。考虑使用异步非阻塞编程模型（如WebFlux）或引入线程池进行异步处理。
    3. JMeter配置或压力机瓶颈 ： 这是最容易被忽略的一点！ 回到“踩坑记录五”。
    4. 连接池配置不当 ：连接池最大连接数设置过小，导致大部分线程在等待获取数据库连接，无法充分利用CPU。

踩坑记录五：忽略压力机自身瓶颈，误判应用性能

  • 现象 ：模拟500并发时，吞吐量卡在800 QPS上不去。应用服务器CPU才用到30%，网络带宽也远未打满。
  • 原因与解决 ：登录压力机一看，好家伙，4核CPU已经被JMeter进程吃满了！JMeter是Java应用，单机模拟高并发时，其自身调度线程、处理响应、收集结果都需要消耗大量CPU资源。当它成为瓶颈时，就无法发出更多请求了。
    • 解决方案1（垂直扩展） ：提升压力机配置，使用更多核心、更高主频的CPU。
    • 解决方案2（水平扩展 - 分布式压测） ：这是更专业的做法。使用一台JMeter控制机（Master），调度多台压力机（Slave）共同施压。具体步骤：
      1. 在所有Slave机器上安装相同版本的JMeter。
      2. 在Slave机器的 jmeter.properties 中设置 server_port=1099 和 server.rmi.localport=1099 ，并启动 jmeter-server 。
      3. 在Master机器的 jmeter.properties 中配置所有Slave的IP地址。
      4. 在Master的GUI中，运行远程启动所有Slave，或者通过命令行指定 -R slave1_ip,slave2_ip,... 。
    • 解决方案3（优化脚本） ：精简监听器，尤其避免在压测中使用“查看结果树”这种极其耗资源的监听器。使用非GUI模式，并将结果写入简单的 .jtl 文件，事后再用GUI导入分析。

7. 将压测融入CI/CD流程

手动压测毕竟效率低。对于追求快速迭代的团队，可以考虑将性能测试左移，集成到持续集成/持续部署（CI/CD）流程中。

  1. 基准测试（Baseline Test） ：在每次代码合并到主分支后，自动执行一个轻量级的性能基准测试（例如，50并发，持续3分钟）。使用JMeter命令行运行脚本，并设定关键指标（如p95响应时间）的阈值。如果结果劣化超过一定比例（如10%），则自动失败并通知开发人员。这能防止性能回归。
  2. 环境与数据隔离 ：CI/CD流水线中需要有一套专用的、可快速重置的性能测试环境。数据库可以使用Docker容器每次构建时从基线数据快照恢复，确保测试数据的一致性。
  3. 结果自动化分析 ：利用JMeter的API或插件，将 .jtl 结果文件解析，并上传到性能数据平台（如InfluxDB + Grafana），形成历史趋势图，直观展示每次构建的性能变化。

这个过程初期搭建有一定成本，但一旦跑通，就能为系统性能提供一个持续的、自动化的守护，价值巨大。

最后，我想强调的是，压力测试不是一个一次性的任务，而是一个持续的过程。随着业务增长、代码变更、数据量膨胀，系统的性能表现会发生变化。定期（如每季度或每次大版本前）回归测试，并与历史基线进行对比，是保持系统健康运行的必备手段。工具（JMeter）只是帮手，真正的核心在于你对系统架构的理解、对业务场景的把握以及从测试数据中发现问题、定位瓶颈、推动优化的能力。希望我踩过的这些坑，能让你在SpringBoot项目上线的路上走得更稳一些。

# 压力测试
Logo
亚马逊云科技技术品牌专区

更多推荐

LoRA（低秩适配）：大模型高效微调的革命性技术

LoRA（低秩适配）是一种高效的大模型微调技术，通过冻结预训练模型权重并注入低秩可训练矩阵，显著降低计算和存储成本。相比全量微调，LoRA参数减少90%以上，显存需求降至3-8GB，训练时间缩短至数小时，且支持灵活任务切换。其核心优势包括低硬件门槛、高效训练和部署灵活性，适用于垂直领域适配、生成式AI定制等场景。经验表明，秩r=4或8通常效果良好，但LoRA在数据量极大或任务复杂时可能受限。技术演

avatar 亚马逊云科技技术品牌专区
cover

【硬件+APP+云平台】9.智能洗衣系统-WiFi-基于STM32嵌入式物联网单片机软硬件毕业生系统设计

avatar 亚马逊云科技技术品牌专区

基于51单片机wifi烟雾温湿度检测 无线物联网 火灾报警系统2114(设计源文件+万字报告+讲解)（支持资料、图片参考_相关定制）_文章底部可以扫码

基于51单片机wifi烟雾温湿度检测 无线物联网 火灾报警系统2114(设计源文件+万字报告+讲解)（支持资料、图片参考_相关定制）_文章底部可以扫码。蜂鸣器声光报警+烟雾MQ-2+ADC0832+DHT11温湿度。51单片机+最小系统+led指示灯+ESP8266。

avatar 亚马逊云科技技术品牌专区