1. 项目概述为什么高并发压测是系统稳定性的“体检中心”最近在复盘几个线上故障发现十有八九都跟性能瓶颈有关。某个看似不起眼的接口在流量洪峰下突然响应时间飙升甚至直接拖垮整个服务集群。这让我再次确信性能测试尤其是模拟真实高并发场景的压力测试绝不是上线前的“选修课”而是保障系统生命线的“必修课”。它就像给系统做一次全面的“压力体检”在真实用户涌入之前提前发现潜在的心血管疾病如线程池耗尽、数据库连接池打满、缓存击穿和骨骼强度问题如CPU过载、内存泄漏。这次我们聚焦两个业界主流的压测工具JMeter和Gatling。JMeter是老牌劲旅功能全面、社区资源丰富像一把瑞士军刀Gatling则是后起之秀基于Scala和Akka以高性能和优雅的DSL领域特定语言脚本著称更像一把精准的手术刀。很多人会问到底该选哪个我的经验是没有最好的工具只有最合适的场景。JMeter适合需要快速搭建、测试场景复杂如涉及多种协议、需要图形化编排的团队而Gatling则更适合追求极致性能、测试脚本需要版本化管理、并希望生成专业报告的性能专家或开发人员。本实战指南我将带你从零开始手把手完成一次完整的高并发性能测试。核心不是简单地跑个脚本而是深入剖析测试场景如何设计才能模拟真实流量、如何解读纷繁复杂的测试结果数据以及在JMeter和Gatling中分别如何实现。无论你是测试工程师、后端开发还是运维负责人都能从中获得可直接复用的方法论和实操技巧。2. 压测工具选型JMeter与Gatling的深度对比与抉择在搭建压测体系前第一个灵魂拷问就是用JMeter还是Gatling网上对比文章很多但大多流于表面。我结合自己多次踩坑的经验从几个核心维度帮你做一次深度拆解。2.1 架构与性能底层的差异这是决定两者表现的根本。JMeter是基于Java线程模型的多线程工具。它为每个虚拟用户VU分配一个独立的Java线程。当并发数上升到几千时线程切换和内存开销会变得非常显著一台压测机可能自己先扛不住了导致结果失真。为了模拟更高并发通常需要部署分布式集群。Gatling的架构则先进一代。它基于Akka工具包和异步非阻塞的IO模型。Gatling内部有一个高效的“事件循环”用少量线程默认和CPU核数相关就能驱动成千上万的虚拟用户。这些虚拟用户被建模为轻量级的“消息”或“行为链”由事件循环调度执行。这意味着Gatling的资源消耗特别是内存和线程远低于JMeter单机就能轻松模拟数万甚至十万级并发数据更接近真实。注意JMeter的线程模型限制并不意味着它不好。对于几千并发的常规测试它完全够用。但如果你需要模拟“双十一”级别的流量冲击或者压测机资源有限Gatling的架构优势就无可比拟。2.2 脚本开发与维护体验这是影响团队协作效率的关键。JMeter提供图形化界面GUI通过拖拽元件如线程组、取样器、监听器来构建测试计划。这对于新手和快速原型构建非常友好。但它的缺点也明显GUI生成的.jmx文件是XML格式可读性差在版本控制中难以进行diff和code review。而且复杂的逻辑控制如复杂的参数化、条件跳转在GUI里配置起来会非常繁琐。Gatling坚持代码即脚本的原则。测试场景用Scala DSL编写也支持Java和Kotlin。虽然需要一点编程基础但带来的好处是巨大的可维护性强脚本是纯文本可以用Git管理方便协作、评审和回滚。灵活度高你可以使用所有Scala/Java语言特性来实现复杂的业务逻辑、数据生成和断言。易于复用可以轻松地将公共方法如登录、获取令牌抽象成函数在不同测试场景中调用。// Gatling DSL示例一个简单的HTTP请求场景 val scn scenario(“BasicSimulation”) .exec(http(“request_homepage”) .get(“/”) .check(status.is(200))) .pause(5) // 模拟用户思考时间这段代码清晰表达了用户访问首页检查状态码是否为200然后等待5秒。任何开发人员都能一目了然。2.3 结果分析与报告呈现压测的最终目的是为了得出可信的结论报告至关重要。JMeter的GUI提供了丰富的监听器如聚合报告、图形结果可以实时查看。但它的默认报告比较简陋高级图表需要安装插件。将结果数据.jtl文件持久化并生成美观的HTML报告需要搭配额外的后端如InfluxDB和前端如Grafana搭建监控仪表盘过程稍显复杂。Gatling在这方面是“开箱即用”的典范。每次运行结束后它都会自动在target/gatling目录下生成一份非常专业的HTML报告。这份报告不仅美观而且信息密度极高直接包含了全局指标仪表盘总请求数、成功率、吞吐量QPS。响应时间分布图清晰展示百分比响应时间如p95, p99这比平均响应时间更有价值。活动用户随时间变化图。错误统计和详情。 报告是静态HTML可以方便地存档或分享给非技术人员查看沟通成本极低。选型决策矩阵 为了帮你快速决策我总结了一个简单的对照表特性维度Apache JMeterGatling核心架构多线程同步阻塞异步事件驱动非阻塞资源消耗较高线程/内存较低单机可模拟更高并发脚本编写图形化GUI生成.jmx代码DSLScala/Java/Kotlin脚本可维护性较差XML格式难diff优秀纯文本易版本管理学习曲线较低上手快中等需基础编程知识报告生成需额外配置或依赖插件内置自动生成精美HTML报告协议支持极其广泛HTTP, JDBC, JMS, TCP等主要聚焦HTTP/WebSocket其他需插件社区生态非常庞大插件丰富活跃但相对小众我的建议选择JMeter如果你的团队测试技能栈偏传统测试场景涉及多种协议如FTP、数据库或者你需要快速进行一些探索性、临时性的测试。选择Gatling如果你的团队具备开发能力追求高效、可维护的压测脚本需要单机模拟超高并发并且希望拥有开箱即用的专业报告。3. 测试场景设计从业务模型到压测脚本的转化艺术压测最忌讳的就是“为了压而压”。拿一个不合理的场景去测试得出的结果毫无意义甚至会产生误导。设计测试场景本质上是将真实的用户行为模型翻译成压测工具能执行的脚本。这个过程我称之为“转化艺术”。3.1 核心四要素并发模型、业务脚本、测试数据、监控指标一个完整的测试场景必须定义清楚以下四点并发模型负载模型用户如何进入和退出系统。同步并发所有虚拟用户在同一时刻开始发送请求。常用于瞬间峰值压力测试如秒杀、抢券。阶梯式递增并发用户数随时间逐步增加如每30秒增加50用户。用于探测系统在不同负载下的表现拐点。波浪式峰谷模拟业务流量高峰和低谷的周期性变化。更贴近多数互联网产品的日常流量模式。脉冲式在极短时间内注入巨大流量然后恢复。模拟热点事件、微博热搜等场景。在JMeter中这主要通过线程组和定时器来配置。在Gatling中则在Scenario的inject方法中定义如rampUsers(100).during(1 minute)表示在1分钟内逐步启动100个用户。业务脚本事务/请求链模拟一个完整用户会话Session所执行的操作序列。例如一个电商用户的操作链可能是首页浏览 - 搜索商品 - 查看商品详情 - 添加购物车 - 登录 - 提交订单 - 支付。关键点要在请求间加入合理的思考时间Pacing Time和步进时间Ramp-up Time。思考时间模拟用户阅读、点击的间隔避免产生不现实的“机枪”式请求。JMeter用Constant TimerGatling用pause方法实现。测试数据参数化与数据池避免所有用户使用同一份数据导致缓存命中率虚高测试失真。需要准备海量、符合业务规则的测试数据。常见方式CSV文件最通用。JMeter用CSV Data Set Config元件Gatling用feed(csv(“file.csv”).circular)。数据库读取从测试数据库实时获取数据。动态生成使用代码或函数助手动态生成如随机用户名、手机号。JMeter有__Random、__time等函数Gatling可以调用Scala/Java代码。数据策略顺序读取、随机读取、唯一性读取每个用户数据不重复。根据业务选择例如注册场景需要唯一数据。监控指标What to Measure定义清楚我们要观察什么。这决定了我们在脚本里要添加哪些“监听器”或“断言”。系统层面服务器CPU、内存、磁盘IO、网络带宽。这通常需要配合运维监控工具如Prometheus, Zabbix。应用层面JVM GC情况、线程池状态、数据库连接池使用率、中间件队列长度。业务层面核心吞吐量Throughput/QPS单位时间处理的请求数。是系统处理能力的直接体现。响应时间Response Time特别是百分位数Percentile如P95、P99。它告诉我们“绝大多数用户的体验”比平均响应时间更有参考价值。比如P99响应时间为200ms意味着99%的用户请求在200ms内返回。错误率Error Rate失败请求的占比。通常要求低于0.1%或更低。并发用户数Concurrent Users当前活跃的虚拟用户数。3.2 设计一个真实的电商秒杀场景假设我们要为一个“限时秒杀”活动做压测。这个场景的特点是瞬时超高并发、读多写少、对库存操作要求强一致性。步骤一分析业务模型核心事务进入秒杀页面 - 点击“立即抢购” - 提交订单。用户行为99%的用户在活动开始瞬间涌入不断刷新页面读直到看到“立即抢购”按钮亮起然后疯狂点击写。数据要求商品ID是固定的但用户Token和地址等信息需要参数化。步骤二转化为JMeter测试计划线程组设置5000个线程Ramp-Up Period设为1秒模拟瞬间并发循环次数设为1每个用户只抢一次。HTTP请求默认值配置协议、服务器地址、端口等公共信息。业务逻辑控制器首先添加一个Once Only Controller里面放登录请求确保每个线程只登录一次获取Token。然后添加一个Loop Controller模拟用户不断刷新。里面放查询秒杀商品详情的请求使用While ControllerJSON Extractor判断按钮状态是否变为“可点击”。一旦检测到可点击跳出循环执行提交秒杀请求。这个请求需要携带Token和商品ID。参数化使用CSV Data Set Config读取用户账号和Token文件。定时器在“刷新详情”请求后添加一个Constant Timer设置100-300ms的随机延迟模拟网络延迟和用户操作间隔。监听器添加聚合报告、响应时间图并将结果树保存到文件.jtl注意正式压测时要禁用查看结果树因为它非常耗内存。步骤三转化为Gatling脚本import scala.concurrent.duration._ import io.gatling.core.Predef._ import io.gatling.http.Predef._ class SeckillSimulation extends Simulation { val httpProtocol http.baseUrl(“http://your-seckill-site.com“) // 1. 读取用户数据 val userFeeder csv(“users.csv”).circular // 2. 定义业务场景 val scn scenario(“SeckillUser”) .feed(userFeeder) .exec( http(“Get Seckill Detail”) // 循环刷新详情页 .get(“/seckill/item/${itemId}“) .header(“Authorization”, “Bearer ${token}“) .check(jsonPath(“$.status”).is(“ACTIVE”)) // 检查商品状态 ) .asLongAs(session session(“itemActive”).asOption[String].isEmpty) { // 如果状态不是ACTIVE暂停后继续检查 pause(100.milliseconds, 300.milliseconds) .exec(http(“Refresh Detail”) .get(“/seckill/item/${itemId}“) .check(jsonPath(“$.status”).saveAs(“itemActive”))) } .exec( // 状态变为ACTIVE后提交请求 http(“Submit Seckill”) .post(“/seckill/submit”) .header(“Authorization”, “Bearer ${token}“) .formParam(“itemId”, “${itemId}“) .check(status.is(200)) ) // 3. 设置负载模型5000用户瞬间启动 setUp( scn.inject(atOnceUsers(5000)) ).protocols(httpProtocol) }这个脚本清晰地定义了用户行为携带Token不断查询商品状态直到可抢购时立刻提交。实操心得设计场景时一定要和产品、开发同学对齐理解最核心、最可能出问题的用户路径。压测脚本不是功能测试脚本的堆砌而是要抓住流量最大、逻辑最复杂、资源最敏感的那条链路。4. 实战演练JMeter与Gatling压测执行全流程理论说得再多不如亲手跑一遍。下面我分别以JMeter和Gatling为例展示一个完整的HTTP API压测流程从环境准备到脚本执行。4.1 JMeter压测实战从安装到生成报告4.1.1 环境准备与脚本录制安装从Apache官网下载JMeter解压即可。确保系统已安装JDK 8或以上版本。可以通过jmeter -v验证。快速创建脚本推荐使用“录制控制器”对于复杂的Web操作手动添加请求很麻烦。可以使用JMeter的HTTP(S) Test Script Recorder。启动JMeter添加一个线程组。在工作台添加HTTP(S) Test Script Recorder。在浏览器或手机端设置代理地址localhost端口8888即JMeter Recorder的默认端口。点击Recorder的Start按钮然后在浏览器中正常操作你的Web应用。操作结束后停止录制你会在线程组下看到自动生成的所有HTTP请求。关键步骤录制后务必进行“清洗”和“参数化”。删除无关的静态资源请求如.css, .js, 图片将登录信息、会话ID等动态值替换为变量或提取器。4.1.2 关键元件配置详解线程组这是负载的起点。线程数即虚拟用户数。Ramp-Up Period很重要设为0表示同时启动这会给系统带来巨大冲击设为线程数秒则表示每秒启动一个用户负载是逐步增加的。HTTP请求填写协议、服务器名称、端口、路径和方法。在“高级”标签页可以设置连接和响应超时时间如5000ms避免线程因等待而阻塞。断言用于验证响应是否正确。常用响应断言检查响应文本是否包含特定关键字或JSON Path提取的值是否符合预期。断言失败该请求会被记为失败。监听器用于收集和查看结果。注意查看结果树和用表格查看结果会消耗大量内存只用于调试。正式压测时应该使用聚合报告、Summary Report并搭配Simple Data Writer将结果写入.jtl文件。# 在JMeter的bin目录下修改jmeter.properties启用并配置结果文件输出 # jmeter.save.saveservice.output_formatcsv # 然后通过命令行指定结果文件路径4.1.3 命令行执行与报告生成GUI模式只适合调试和少量并发。正式压测一定要用非GUI命令行模式以减少资源开销。# 切换到JMeter的bin目录下执行 jmeter -n -t your_test_plan.jmx -l result.jtl -e -o ./report-n: 非GUI模式-t: 指定测试计划文件-l: 指定结果日志文件.jtl-e -o: 在测试结束后生成HTML报告并输出到指定目录./report生成的HTML报告包含了丰富的图表和表格比GUI内的监听器更全面。4.2 Gatling压测实战代码化脚本与高效执行4.2.1 环境搭建与项目初始化Gatling的安装更“程序员友好”。推荐使用构建工具。使用Maven/Gradle创建一个新的Maven项目在pom.xml中添加Gatling依赖。dependency groupIdio.gatling/groupId artifactIdgatling-core/artifactId version${gatling.version}/version /dependency使用官方Bundle直接从Gatling官网下载打包好的版本解压即用。里面包含了Recorder用于录制脚本和Engine用于执行。4.2.2 编写第一个压测脚本Gatling的脚本位于src/test/scala目录下。我们写一个简单的例子import io.gatling.core.Predef._ import io.gatling.http.Predef._ import scala.concurrent.duration._ class BasicSimulation extends Simulation { // 1. 定义HTTP协议配置 val httpProtocol http .baseUrl(“http://localhost:8080“) // 基础URL .acceptHeader(“application/json”) .userAgentHeader(“Gatling/Performance Test”) // 2. 定义业务场景Scenario val scn scenario(“Get User Info”) .exec(http(“Get User Request”) .get(“/api/user/123”) .check(status.is(200), jsonPath(“$.name”).is(“John Doe”)) ) .pause(2) // 思考时间2秒 // 3. 注入负载模型并绑定协议 setUp( scn.inject( nothingFor(4.seconds), // 开始前等待4秒 atOnceUsers(10), // 瞬间注入10个用户 rampUsers(50).during(30.seconds), // 30秒内逐步增加到50用户 constantUsersPerSec(2).during(1.minute) // 接下来1分钟保持每秒2用户 ).protocols(httpProtocol) ) }这个脚本定义了一个混合负载模型先瞬间10用户再阶梯增长最后保持恒定压力。4.2.3 执行脚本与查看报告使用IDEA或命令行执行如果你用Maven可以运行mvn gatling:test。如果使用官方Bundle在bin目录下运行./gatling.sh程序会列出所有可用的Simulation选择你要运行的编号即可。报告分析执行完毕后控制台会输出报告路径。直接用浏览器打开index.html。你会看到一个非常直观的仪表盘。重点关注Global部分总请求数、成功率、QPS。Response Time Distribution响应时间百分比表格。P95和P99是黄金指标。Active Users over Time活跃用户数曲线验证负载模型是否符合预期。Response Time over Time响应时间随时间变化曲线结合活跃用户图可以分析系统在压力下的稳定性。注意事项无论是JMeter还是Gatling压测机本身不能成为瓶颈。确保压测机有足够的CPU、内存和网络带宽。对于高并发测试建议使用多台压测机构成集群JMeter分布式或使用云上的高性能虚拟机。5. 结果分析与性能瓶颈定位从数据到决策压测脚本跑完了生成了密密麻麻的数据和图表。别慌我们像侦探一样一步步分析找到系统的“命门”。5.1 核心性能指标解读面对一份压测报告我通常按以下顺序查看吞吐量Throughput/QPS与并发用户数曲线理想情况随着并发用户数增加吞吐量线性增长直到达到一个峰值后趋于平稳。这个峰值就是系统的最大处理能力。异常情况并发用户增加但吞吐量不增反降或剧烈波动。这通常意味着系统内部出现了严重资源竞争或阻塞比如数据库锁、线程池满、频繁Full GC。响应时间Response Time百分位图平均响应时间参考价值有限容易被少数慢请求拉高。中位数P50有一半的请求比这个值快。P90/P95重点关注。例如P95500ms意味着95%的用户体验在500ms以内。这是评估系统是否达标的关键。P99/P999尾延迟反映最慢的那部分请求。如果P99突然飙升可能意味着有慢查询、大对象GC或网络抖动。优化尾延迟对提升用户体验至关重要。错误率Error Rate直接看失败请求的百分比和具体错误类型如5xx服务器错误、4xx客户端错误、连接超时、读取超时。错误率陡增的点往往就是系统的崩溃点。5.2 建立“指标-瓶颈”关联图谱当发现性能指标异常时我们需要快速定位到系统层的瓶颈。我总结了一个简单的关联图谱性能现象压测结果可能的应用层瓶颈可能的系统/中间件层瓶颈吞吐量上不去CPU使用率低线程池配置过小外部依赖如数据库、Redis响应慢代码中存在同步锁竞争。数据库连接池满慢查询网络带宽不足磁盘IO瓶颈。响应时间随并发线性增长逻辑处理耗时未充分利用异步缓存未命中大量请求穿透到数据库。数据库CPU/IO压力大JVM频繁GC导致STWStop-The-World。P99响应时间异常高P50正常存在“慢请求”如个别大查询、循环依赖调用、锁等待。数据库存在行锁/表锁竞争某些中间件节点负载不均。高并发下错误率飙升如5xx线程池耗尽拒绝服务数据库连接池耗尽内存溢出OOM。服务器文件描述符FD耗尽网络连接数满操作系统参数限制如net.core.somaxconn。吞吐量达到某一值后剧烈波动可能触发了限流或熔断机制。系统达到物理资源极限如CPU 100%进程频繁调度。5.3 实战分析案例一个接口的P99延迟过高假设我们压测一个/api/orders查询接口发现当并发达到200时P99响应时间从100ms飙升至2s但CPU使用率只有40%。排查思路查看错误日志首先检查应用日志看是否有大量异常抛出比如TimeoutException或SQLException。监控数据库登录数据库监控发现该时间点有一条SQL的查询时间Query_time突然变长。很可能是因为没有合适的索引或者表数据量太大导致随着并发增加查询效率急剧下降。分析代码逻辑检查该接口的代码发现它在查询订单后还会循环调用另一个服务获取用户详情N1查询问题。在低并发时没问题高并发时这个外部服务成为瓶颈。使用Profiler工具如果日志和监控不明显可以使用ArthasJava或py-spyPython等在线诊断工具attach到应用进程上查看CPU时间到底花在了哪个方法上。解决方案针对数据库慢查询增加索引、优化SQL语句避免SELECT *减少JOIN、考虑读写分离或分库分表。针对N1查询将循环调用改为批量查询或者使用缓存如Redis存储用户详情。针对外部依赖慢为外部调用设置合理的超时时间和熔断机制避免一个慢服务拖垮整个应用。实操心得压测结果分析一定要结合应用日志、系统监控如CPU、内存、IO和中间件监控如数据库、Redis、MQ进行联动分析。单独看压测工具的报告就像医生只看体温计是看不出病因的。压测过程中在服务器上运行一些快速命令很有帮助比如top看CPU、vmstat 1看系统瓶颈、iostat -x 1看磁盘IO、netstat -an | grep TIME_WAIT | wc -l看连接状态。6. 常见问题与排查技巧实录在多年的压测实践中我踩过无数的坑。这里把一些高频问题和解决技巧记录下来希望能帮你少走弯路。6.1 压测工具本身的问题问题1JMeter在GUI模式下运行高并发测试时卡死或无响应。原因GUI模式本身消耗大量资源来渲染图表不适合做高并发压测。解决永远在非GUI命令行模式下执行正式压测。使用-n和-t参数。调试时可以用GUI但线程数不要设太高。问题2Gatling报告中的QPS远低于预期。原因可能是在脚本中设置了过长的pause思考时间或者ramp-up时间设置得太长导致单位时间内发出的请求数不足。解决检查负载模型inject部分。如果想测试系统极限吞吐量可以使用constantUsersPerSec或rampUsersPerSec并减少或移除pause。思考时间模拟的是真实用户行为在测试极限能力时可以暂时去掉。问题3压测机网络或CPU先达到瓶颈导致结果不准。原因单台压测机模拟的并发数或发出的网络流量超过了其硬件能力。解决监控压测机资源压测时用top、iftop等工具监控压测机自身状态。使用分布式压测对于JMeter可以搭建Master-Slave集群。将脚本分发到多台Slave机器上执行由Master汇总结果。提升压测机配置使用网络带宽更高、CPU核心更多的机器。在云平台上选择计算优化型实例。6.2 被测系统环境与配置问题问题4压测时出现大量“Connection refused”或“Socket timeout”错误。原因服务器端的端口连接数或文件描述符FD达到操作系统限制。服务器线程池或数据库连接池被耗尽。排查与解决在服务器上执行ss -s或netstat -an | grep ESTABLISHED | wc -l查看当前连接数。检查Linux系统限制ulimit -n文件描述符数sysctl net.core.somaxconnTCP连接队列大小。根据需要调大这些参数。检查应用配置如Web服务器的maxThreads数据库连接池的maxActive参数确保其足够大以应对高并发。问题5随着压测时间推移响应时间越来越慢最终可能OOM内存溢出。原因典型的内存泄漏问题。可能是缓存没有设置过期时间或大小限制导致内存被无限占用也可能是数据库连接、文件流等资源没有正确关闭。排查监控服务器的内存使用情况观察是否持续增长而不回落。使用JVM工具如jmap -histo:live查看堆内存中的对象分布找出疑似泄漏的对象类。在压测脚本中模拟更长时间如30分钟以上的稳定性测试耐力测试更容易暴露此类问题。6.3 脚本设计与数据问题问题6所有请求都成功但业务逻辑其实失败了比如秒杀超卖。原因压测脚本只检查了HTTP状态码如200但没有检查响应体中的业务状态码。可能接口返回了{“code”: 500, “msg”: “库存不足”}但HTTP状态仍是200。解决在压测脚本中增加业务断言。JMeter使用JSON Extractor响应断言Gatling使用.check(jsonPath(“$.code”).is(0))。确保只有业务成功的请求才被统计为成功。问题7测试初期性能很好几分钟后急剧下降。原因可能是缓存失效或数据库连接池预热问题。开始时缓存是热的数据库连接池是空的。运行一段时间后缓存过期大量请求直接打到数据库同时连接池已满但可能包含一些僵死连接。解决在正式压测前先进行预热Warm-up。用低并发运行脚本几分钟让JVM完成JIT编译让缓存加载数据让连接池初始化。在Gatling中可以使用nothingFor和rampUsers组合来实现预热阶段。在JMeter中可以单独设置一个预热用的线程组先跑一段时间。问题8参数化数据很快用完导致后续请求失败。原因CSV文件中测试数据行数少于虚拟用户数*循环次数。解决设置CSV数据文件的读取策略。在JMeter的CSV Data Set Config中将Recycle on EOF?设为True循环读取Stop thread on EOF?设为False。在Gatling中使用.circular策略。对于需要唯一性的数据如用户名务必准备足够多的数据或使用代码动态生成。性能测试是一个持续迭代和深入挖掘的过程。一次压测不是终点而是发现系统脆弱点的开始。根据分析结果进行优化代码、架构、配置然后再次压测验证如此循环才能让系统在真正的流量洪峰前稳如磐石。记住压测的价值不在于得到一个漂亮的数字而在于提前发现并解决那些“如果线上发生就是P0事故”的问题。
高并发压测实战：JMeter与Gatling选型、场景设计与瓶颈定位
发布时间：2026/6/22 21:56:28
1. 项目概述为什么高并发压测是系统稳定性的“体检中心”最近在复盘几个线上故障发现十有八九都跟性能瓶颈有关。某个看似不起眼的接口在流量洪峰下突然响应时间飙升甚至直接拖垮整个服务集群。这让我再次确信性能测试尤其是模拟真实高并发场景的压力测试绝不是上线前的“选修课”而是保障系统生命线的“必修课”。它就像给系统做一次全面的“压力体检”在真实用户涌入之前提前发现潜在的心血管疾病如线程池耗尽、数据库连接池打满、缓存击穿和骨骼强度问题如CPU过载、内存泄漏。这次我们聚焦两个业界主流的压测工具JMeter和Gatling。JMeter是老牌劲旅功能全面、社区资源丰富像一把瑞士军刀Gatling则是后起之秀基于Scala和Akka以高性能和优雅的DSL领域特定语言脚本著称更像一把精准的手术刀。很多人会问到底该选哪个我的经验是没有最好的工具只有最合适的场景。JMeter适合需要快速搭建、测试场景复杂如涉及多种协议、需要图形化编排的团队而Gatling则更适合追求极致性能、测试脚本需要版本化管理、并希望生成专业报告的性能专家或开发人员。本实战指南我将带你从零开始手把手完成一次完整的高并发性能测试。核心不是简单地跑个脚本而是深入剖析测试场景如何设计才能模拟真实流量、如何解读纷繁复杂的测试结果数据以及在JMeter和Gatling中分别如何实现。无论你是测试工程师、后端开发还是运维负责人都能从中获得可直接复用的方法论和实操技巧。2. 压测工具选型JMeter与Gatling的深度对比与抉择在搭建压测体系前第一个灵魂拷问就是用JMeter还是Gatling网上对比文章很多但大多流于表面。我结合自己多次踩坑的经验从几个核心维度帮你做一次深度拆解。2.1 架构与性能底层的差异这是决定两者表现的根本。JMeter是基于Java线程模型的多线程工具。它为每个虚拟用户VU分配一个独立的Java线程。当并发数上升到几千时线程切换和内存开销会变得非常显著一台压测机可能自己先扛不住了导致结果失真。为了模拟更高并发通常需要部署分布式集群。Gatling的架构则先进一代。它基于Akka工具包和异步非阻塞的IO模型。Gatling内部有一个高效的“事件循环”用少量线程默认和CPU核数相关就能驱动成千上万的虚拟用户。这些虚拟用户被建模为轻量级的“消息”或“行为链”由事件循环调度执行。这意味着Gatling的资源消耗特别是内存和线程远低于JMeter单机就能轻松模拟数万甚至十万级并发数据更接近真实。注意JMeter的线程模型限制并不意味着它不好。对于几千并发的常规测试它完全够用。但如果你需要模拟“双十一”级别的流量冲击或者压测机资源有限Gatling的架构优势就无可比拟。2.2 脚本开发与维护体验这是影响团队协作效率的关键。JMeter提供图形化界面GUI通过拖拽元件如线程组、取样器、监听器来构建测试计划。这对于新手和快速原型构建非常友好。但它的缺点也明显GUI生成的.jmx文件是XML格式可读性差在版本控制中难以进行diff和code review。而且复杂的逻辑控制如复杂的参数化、条件跳转在GUI里配置起来会非常繁琐。Gatling坚持代码即脚本的原则。测试场景用Scala DSL编写也支持Java和Kotlin。虽然需要一点编程基础但带来的好处是巨大的可维护性强脚本是纯文本可以用Git管理方便协作、评审和回滚。灵活度高你可以使用所有Scala/Java语言特性来实现复杂的业务逻辑、数据生成和断言。易于复用可以轻松地将公共方法如登录、获取令牌抽象成函数在不同测试场景中调用。// Gatling DSL示例一个简单的HTTP请求场景 val scn scenario(“BasicSimulation”) .exec(http(“request_homepage”) .get(“/”) .check(status.is(200))) .pause(5) // 模拟用户思考时间这段代码清晰表达了用户访问首页检查状态码是否为200然后等待5秒。任何开发人员都能一目了然。2.3 结果分析与报告呈现压测的最终目的是为了得出可信的结论报告至关重要。JMeter的GUI提供了丰富的监听器如聚合报告、图形结果可以实时查看。但它的默认报告比较简陋高级图表需要安装插件。将结果数据.jtl文件持久化并生成美观的HTML报告需要搭配额外的后端如InfluxDB和前端如Grafana搭建监控仪表盘过程稍显复杂。Gatling在这方面是“开箱即用”的典范。每次运行结束后它都会自动在target/gatling目录下生成一份非常专业的HTML报告。这份报告不仅美观而且信息密度极高直接包含了全局指标仪表盘总请求数、成功率、吞吐量QPS。响应时间分布图清晰展示百分比响应时间如p95, p99这比平均响应时间更有价值。活动用户随时间变化图。错误统计和详情。 报告是静态HTML可以方便地存档或分享给非技术人员查看沟通成本极低。选型决策矩阵 为了帮你快速决策我总结了一个简单的对照表特性维度Apache JMeterGatling核心架构多线程同步阻塞异步事件驱动非阻塞资源消耗较高线程/内存较低单机可模拟更高并发脚本编写图形化GUI生成.jmx代码DSLScala/Java/Kotlin脚本可维护性较差XML格式难diff优秀纯文本易版本管理学习曲线较低上手快中等需基础编程知识报告生成需额外配置或依赖插件内置自动生成精美HTML报告协议支持极其广泛HTTP, JDBC, JMS, TCP等主要聚焦HTTP/WebSocket其他需插件社区生态非常庞大插件丰富活跃但相对小众我的建议选择JMeter如果你的团队测试技能栈偏传统测试场景涉及多种协议如FTP、数据库或者你需要快速进行一些探索性、临时性的测试。选择Gatling如果你的团队具备开发能力追求高效、可维护的压测脚本需要单机模拟超高并发并且希望拥有开箱即用的专业报告。3. 测试场景设计从业务模型到压测脚本的转化艺术压测最忌讳的就是“为了压而压”。拿一个不合理的场景去测试得出的结果毫无意义甚至会产生误导。设计测试场景本质上是将真实的用户行为模型翻译成压测工具能执行的脚本。这个过程我称之为“转化艺术”。3.1 核心四要素并发模型、业务脚本、测试数据、监控指标一个完整的测试场景必须定义清楚以下四点并发模型负载模型用户如何进入和退出系统。同步并发所有虚拟用户在同一时刻开始发送请求。常用于瞬间峰值压力测试如秒杀、抢券。阶梯式递增并发用户数随时间逐步增加如每30秒增加50用户。用于探测系统在不同负载下的表现拐点。波浪式峰谷模拟业务流量高峰和低谷的周期性变化。更贴近多数互联网产品的日常流量模式。脉冲式在极短时间内注入巨大流量然后恢复。模拟热点事件、微博热搜等场景。在JMeter中这主要通过线程组和定时器来配置。在Gatling中则在Scenario的inject方法中定义如rampUsers(100).during(1 minute)表示在1分钟内逐步启动100个用户。业务脚本事务/请求链模拟一个完整用户会话Session所执行的操作序列。例如一个电商用户的操作链可能是首页浏览 - 搜索商品 - 查看商品详情 - 添加购物车 - 登录 - 提交订单 - 支付。关键点要在请求间加入合理的思考时间Pacing Time和步进时间Ramp-up Time。思考时间模拟用户阅读、点击的间隔避免产生不现实的“机枪”式请求。JMeter用Constant TimerGatling用pause方法实现。测试数据参数化与数据池避免所有用户使用同一份数据导致缓存命中率虚高测试失真。需要准备海量、符合业务规则的测试数据。常见方式CSV文件最通用。JMeter用CSV Data Set Config元件Gatling用feed(csv(“file.csv”).circular)。数据库读取从测试数据库实时获取数据。动态生成使用代码或函数助手动态生成如随机用户名、手机号。JMeter有__Random、__time等函数Gatling可以调用Scala/Java代码。数据策略顺序读取、随机读取、唯一性读取每个用户数据不重复。根据业务选择例如注册场景需要唯一数据。监控指标What to Measure定义清楚我们要观察什么。这决定了我们在脚本里要添加哪些“监听器”或“断言”。系统层面服务器CPU、内存、磁盘IO、网络带宽。这通常需要配合运维监控工具如Prometheus, Zabbix。应用层面JVM GC情况、线程池状态、数据库连接池使用率、中间件队列长度。业务层面核心吞吐量Throughput/QPS单位时间处理的请求数。是系统处理能力的直接体现。响应时间Response Time特别是百分位数Percentile如P95、P99。它告诉我们“绝大多数用户的体验”比平均响应时间更有参考价值。比如P99响应时间为200ms意味着99%的用户请求在200ms内返回。错误率Error Rate失败请求的占比。通常要求低于0.1%或更低。并发用户数Concurrent Users当前活跃的虚拟用户数。3.2 设计一个真实的电商秒杀场景假设我们要为一个“限时秒杀”活动做压测。这个场景的特点是瞬时超高并发、读多写少、对库存操作要求强一致性。步骤一分析业务模型核心事务进入秒杀页面 - 点击“立即抢购” - 提交订单。用户行为99%的用户在活动开始瞬间涌入不断刷新页面读直到看到“立即抢购”按钮亮起然后疯狂点击写。数据要求商品ID是固定的但用户Token和地址等信息需要参数化。步骤二转化为JMeter测试计划线程组设置5000个线程Ramp-Up Period设为1秒模拟瞬间并发循环次数设为1每个用户只抢一次。HTTP请求默认值配置协议、服务器地址、端口等公共信息。业务逻辑控制器首先添加一个Once Only Controller里面放登录请求确保每个线程只登录一次获取Token。然后添加一个Loop Controller模拟用户不断刷新。里面放查询秒杀商品详情的请求使用While ControllerJSON Extractor判断按钮状态是否变为“可点击”。一旦检测到可点击跳出循环执行提交秒杀请求。这个请求需要携带Token和商品ID。参数化使用CSV Data Set Config读取用户账号和Token文件。定时器在“刷新详情”请求后添加一个Constant Timer设置100-300ms的随机延迟模拟网络延迟和用户操作间隔。监听器添加聚合报告、响应时间图并将结果树保存到文件.jtl注意正式压测时要禁用查看结果树因为它非常耗内存。步骤三转化为Gatling脚本import scala.concurrent.duration._ import io.gatling.core.Predef._ import io.gatling.http.Predef._ class SeckillSimulation extends Simulation { val httpProtocol http.baseUrl(“http://your-seckill-site.com“) // 1. 读取用户数据 val userFeeder csv(“users.csv”).circular // 2. 定义业务场景 val scn scenario(“SeckillUser”) .feed(userFeeder) .exec( http(“Get Seckill Detail”) // 循环刷新详情页 .get(“/seckill/item/${itemId}“) .header(“Authorization”, “Bearer ${token}“) .check(jsonPath(“$.status”).is(“ACTIVE”)) // 检查商品状态 ) .asLongAs(session session(“itemActive”).asOption[String].isEmpty) { // 如果状态不是ACTIVE暂停后继续检查 pause(100.milliseconds, 300.milliseconds) .exec(http(“Refresh Detail”) .get(“/seckill/item/${itemId}“) .check(jsonPath(“$.status”).saveAs(“itemActive”))) } .exec( // 状态变为ACTIVE后提交请求 http(“Submit Seckill”) .post(“/seckill/submit”) .header(“Authorization”, “Bearer ${token}“) .formParam(“itemId”, “${itemId}“) .check(status.is(200)) ) // 3. 设置负载模型5000用户瞬间启动 setUp( scn.inject(atOnceUsers(5000)) ).protocols(httpProtocol) }这个脚本清晰地定义了用户行为携带Token不断查询商品状态直到可抢购时立刻提交。实操心得设计场景时一定要和产品、开发同学对齐理解最核心、最可能出问题的用户路径。压测脚本不是功能测试脚本的堆砌而是要抓住流量最大、逻辑最复杂、资源最敏感的那条链路。4. 实战演练JMeter与Gatling压测执行全流程理论说得再多不如亲手跑一遍。下面我分别以JMeter和Gatling为例展示一个完整的HTTP API压测流程从环境准备到脚本执行。4.1 JMeter压测实战从安装到生成报告4.1.1 环境准备与脚本录制安装从Apache官网下载JMeter解压即可。确保系统已安装JDK 8或以上版本。可以通过jmeter -v验证。快速创建脚本推荐使用“录制控制器”对于复杂的Web操作手动添加请求很麻烦。可以使用JMeter的HTTP(S) Test Script Recorder。启动JMeter添加一个线程组。在工作台添加HTTP(S) Test Script Recorder。在浏览器或手机端设置代理地址localhost端口8888即JMeter Recorder的默认端口。点击Recorder的Start按钮然后在浏览器中正常操作你的Web应用。操作结束后停止录制你会在线程组下看到自动生成的所有HTTP请求。关键步骤录制后务必进行“清洗”和“参数化”。删除无关的静态资源请求如.css, .js, 图片将登录信息、会话ID等动态值替换为变量或提取器。4.1.2 关键元件配置详解线程组这是负载的起点。线程数即虚拟用户数。Ramp-Up Period很重要设为0表示同时启动这会给系统带来巨大冲击设为线程数秒则表示每秒启动一个用户负载是逐步增加的。HTTP请求填写协议、服务器名称、端口、路径和方法。在“高级”标签页可以设置连接和响应超时时间如5000ms避免线程因等待而阻塞。断言用于验证响应是否正确。常用响应断言检查响应文本是否包含特定关键字或JSON Path提取的值是否符合预期。断言失败该请求会被记为失败。监听器用于收集和查看结果。注意查看结果树和用表格查看结果会消耗大量内存只用于调试。正式压测时应该使用聚合报告、Summary Report并搭配Simple Data Writer将结果写入.jtl文件。# 在JMeter的bin目录下修改jmeter.properties启用并配置结果文件输出 # jmeter.save.saveservice.output_formatcsv # 然后通过命令行指定结果文件路径4.1.3 命令行执行与报告生成GUI模式只适合调试和少量并发。正式压测一定要用非GUI命令行模式以减少资源开销。# 切换到JMeter的bin目录下执行 jmeter -n -t your_test_plan.jmx -l result.jtl -e -o ./report-n: 非GUI模式-t: 指定测试计划文件-l: 指定结果日志文件.jtl-e -o: 在测试结束后生成HTML报告并输出到指定目录./report生成的HTML报告包含了丰富的图表和表格比GUI内的监听器更全面。4.2 Gatling压测实战代码化脚本与高效执行4.2.1 环境搭建与项目初始化Gatling的安装更“程序员友好”。推荐使用构建工具。使用Maven/Gradle创建一个新的Maven项目在pom.xml中添加Gatling依赖。dependency groupIdio.gatling/groupId artifactIdgatling-core/artifactId version${gatling.version}/version /dependency使用官方Bundle直接从Gatling官网下载打包好的版本解压即用。里面包含了Recorder用于录制脚本和Engine用于执行。4.2.2 编写第一个压测脚本Gatling的脚本位于src/test/scala目录下。我们写一个简单的例子import io.gatling.core.Predef._ import io.gatling.http.Predef._ import scala.concurrent.duration._ class BasicSimulation extends Simulation { // 1. 定义HTTP协议配置 val httpProtocol http .baseUrl(“http://localhost:8080“) // 基础URL .acceptHeader(“application/json”) .userAgentHeader(“Gatling/Performance Test”) // 2. 定义业务场景Scenario val scn scenario(“Get User Info”) .exec(http(“Get User Request”) .get(“/api/user/123”) .check(status.is(200), jsonPath(“$.name”).is(“John Doe”)) ) .pause(2) // 思考时间2秒 // 3. 注入负载模型并绑定协议 setUp( scn.inject( nothingFor(4.seconds), // 开始前等待4秒 atOnceUsers(10), // 瞬间注入10个用户 rampUsers(50).during(30.seconds), // 30秒内逐步增加到50用户 constantUsersPerSec(2).during(1.minute) // 接下来1分钟保持每秒2用户 ).protocols(httpProtocol) ) }这个脚本定义了一个混合负载模型先瞬间10用户再阶梯增长最后保持恒定压力。4.2.3 执行脚本与查看报告使用IDEA或命令行执行如果你用Maven可以运行mvn gatling:test。如果使用官方Bundle在bin目录下运行./gatling.sh程序会列出所有可用的Simulation选择你要运行的编号即可。报告分析执行完毕后控制台会输出报告路径。直接用浏览器打开index.html。你会看到一个非常直观的仪表盘。重点关注Global部分总请求数、成功率、QPS。Response Time Distribution响应时间百分比表格。P95和P99是黄金指标。Active Users over Time活跃用户数曲线验证负载模型是否符合预期。Response Time over Time响应时间随时间变化曲线结合活跃用户图可以分析系统在压力下的稳定性。注意事项无论是JMeter还是Gatling压测机本身不能成为瓶颈。确保压测机有足够的CPU、内存和网络带宽。对于高并发测试建议使用多台压测机构成集群JMeter分布式或使用云上的高性能虚拟机。5. 结果分析与性能瓶颈定位从数据到决策压测脚本跑完了生成了密密麻麻的数据和图表。别慌我们像侦探一样一步步分析找到系统的“命门”。5.1 核心性能指标解读面对一份压测报告我通常按以下顺序查看吞吐量Throughput/QPS与并发用户数曲线理想情况随着并发用户数增加吞吐量线性增长直到达到一个峰值后趋于平稳。这个峰值就是系统的最大处理能力。异常情况并发用户增加但吞吐量不增反降或剧烈波动。这通常意味着系统内部出现了严重资源竞争或阻塞比如数据库锁、线程池满、频繁Full GC。响应时间Response Time百分位图平均响应时间参考价值有限容易被少数慢请求拉高。中位数P50有一半的请求比这个值快。P90/P95重点关注。例如P95500ms意味着95%的用户体验在500ms以内。这是评估系统是否达标的关键。P99/P999尾延迟反映最慢的那部分请求。如果P99突然飙升可能意味着有慢查询、大对象GC或网络抖动。优化尾延迟对提升用户体验至关重要。错误率Error Rate直接看失败请求的百分比和具体错误类型如5xx服务器错误、4xx客户端错误、连接超时、读取超时。错误率陡增的点往往就是系统的崩溃点。5.2 建立“指标-瓶颈”关联图谱当发现性能指标异常时我们需要快速定位到系统层的瓶颈。我总结了一个简单的关联图谱性能现象压测结果可能的应用层瓶颈可能的系统/中间件层瓶颈吞吐量上不去CPU使用率低线程池配置过小外部依赖如数据库、Redis响应慢代码中存在同步锁竞争。数据库连接池满慢查询网络带宽不足磁盘IO瓶颈。响应时间随并发线性增长逻辑处理耗时未充分利用异步缓存未命中大量请求穿透到数据库。数据库CPU/IO压力大JVM频繁GC导致STWStop-The-World。P99响应时间异常高P50正常存在“慢请求”如个别大查询、循环依赖调用、锁等待。数据库存在行锁/表锁竞争某些中间件节点负载不均。高并发下错误率飙升如5xx线程池耗尽拒绝服务数据库连接池耗尽内存溢出OOM。服务器文件描述符FD耗尽网络连接数满操作系统参数限制如net.core.somaxconn。吞吐量达到某一值后剧烈波动可能触发了限流或熔断机制。系统达到物理资源极限如CPU 100%进程频繁调度。5.3 实战分析案例一个接口的P99延迟过高假设我们压测一个/api/orders查询接口发现当并发达到200时P99响应时间从100ms飙升至2s但CPU使用率只有40%。排查思路查看错误日志首先检查应用日志看是否有大量异常抛出比如TimeoutException或SQLException。监控数据库登录数据库监控发现该时间点有一条SQL的查询时间Query_time突然变长。很可能是因为没有合适的索引或者表数据量太大导致随着并发增加查询效率急剧下降。分析代码逻辑检查该接口的代码发现它在查询订单后还会循环调用另一个服务获取用户详情N1查询问题。在低并发时没问题高并发时这个外部服务成为瓶颈。使用Profiler工具如果日志和监控不明显可以使用ArthasJava或py-spyPython等在线诊断工具attach到应用进程上查看CPU时间到底花在了哪个方法上。解决方案针对数据库慢查询增加索引、优化SQL语句避免SELECT *减少JOIN、考虑读写分离或分库分表。针对N1查询将循环调用改为批量查询或者使用缓存如Redis存储用户详情。针对外部依赖慢为外部调用设置合理的超时时间和熔断机制避免一个慢服务拖垮整个应用。实操心得压测结果分析一定要结合应用日志、系统监控如CPU、内存、IO和中间件监控如数据库、Redis、MQ进行联动分析。单独看压测工具的报告就像医生只看体温计是看不出病因的。压测过程中在服务器上运行一些快速命令很有帮助比如top看CPU、vmstat 1看系统瓶颈、iostat -x 1看磁盘IO、netstat -an | grep TIME_WAIT | wc -l看连接状态。6. 常见问题与排查技巧实录在多年的压测实践中我踩过无数的坑。这里把一些高频问题和解决技巧记录下来希望能帮你少走弯路。6.1 压测工具本身的问题问题1JMeter在GUI模式下运行高并发测试时卡死或无响应。原因GUI模式本身消耗大量资源来渲染图表不适合做高并发压测。解决永远在非GUI命令行模式下执行正式压测。使用-n和-t参数。调试时可以用GUI但线程数不要设太高。问题2Gatling报告中的QPS远低于预期。原因可能是在脚本中设置了过长的pause思考时间或者ramp-up时间设置得太长导致单位时间内发出的请求数不足。解决检查负载模型inject部分。如果想测试系统极限吞吐量可以使用constantUsersPerSec或rampUsersPerSec并减少或移除pause。思考时间模拟的是真实用户行为在测试极限能力时可以暂时去掉。问题3压测机网络或CPU先达到瓶颈导致结果不准。原因单台压测机模拟的并发数或发出的网络流量超过了其硬件能力。解决监控压测机资源压测时用top、iftop等工具监控压测机自身状态。使用分布式压测对于JMeter可以搭建Master-Slave集群。将脚本分发到多台Slave机器上执行由Master汇总结果。提升压测机配置使用网络带宽更高、CPU核心更多的机器。在云平台上选择计算优化型实例。6.2 被测系统环境与配置问题问题4压测时出现大量“Connection refused”或“Socket timeout”错误。原因服务器端的端口连接数或文件描述符FD达到操作系统限制。服务器线程池或数据库连接池被耗尽。排查与解决在服务器上执行ss -s或netstat -an | grep ESTABLISHED | wc -l查看当前连接数。检查Linux系统限制ulimit -n文件描述符数sysctl net.core.somaxconnTCP连接队列大小。根据需要调大这些参数。检查应用配置如Web服务器的maxThreads数据库连接池的maxActive参数确保其足够大以应对高并发。问题5随着压测时间推移响应时间越来越慢最终可能OOM内存溢出。原因典型的内存泄漏问题。可能是缓存没有设置过期时间或大小限制导致内存被无限占用也可能是数据库连接、文件流等资源没有正确关闭。排查监控服务器的内存使用情况观察是否持续增长而不回落。使用JVM工具如jmap -histo:live查看堆内存中的对象分布找出疑似泄漏的对象类。在压测脚本中模拟更长时间如30分钟以上的稳定性测试耐力测试更容易暴露此类问题。6.3 脚本设计与数据问题问题6所有请求都成功但业务逻辑其实失败了比如秒杀超卖。原因压测脚本只检查了HTTP状态码如200但没有检查响应体中的业务状态码。可能接口返回了{“code”: 500, “msg”: “库存不足”}但HTTP状态仍是200。解决在压测脚本中增加业务断言。JMeter使用JSON Extractor响应断言Gatling使用.check(jsonPath(“$.code”).is(0))。确保只有业务成功的请求才被统计为成功。问题7测试初期性能很好几分钟后急剧下降。原因可能是缓存失效或数据库连接池预热问题。开始时缓存是热的数据库连接池是空的。运行一段时间后缓存过期大量请求直接打到数据库同时连接池已满但可能包含一些僵死连接。解决在正式压测前先进行预热Warm-up。用低并发运行脚本几分钟让JVM完成JIT编译让缓存加载数据让连接池初始化。在Gatling中可以使用nothingFor和rampUsers组合来实现预热阶段。在JMeter中可以单独设置一个预热用的线程组先跑一段时间。问题8参数化数据很快用完导致后续请求失败。原因CSV文件中测试数据行数少于虚拟用户数*循环次数。解决设置CSV数据文件的读取策略。在JMeter的CSV Data Set Config中将Recycle on EOF?设为True循环读取Stop thread on EOF?设为False。在Gatling中使用.circular策略。对于需要唯一性的数据如用户名务必准备足够多的数据或使用代码动态生成。性能测试是一个持续迭代和深入挖掘的过程。一次压测不是终点而是发现系统脆弱点的开始。根据分析结果进行优化代码、架构、配置然后再次压测验证如此循环才能让系统在真正的流量洪峰前稳如磐石。记住压测的价值不在于得到一个漂亮的数字而在于提前发现并解决那些“如果线上发生就是P0事故”的问题。
