拓冰网站定制 
上周线上一个下单接口突然变慢用户在群里截图反馈领导丢了一句“压一下看看能扛多少并发”。我当时第一个想到的是LoadRunner但公司没有License装起来也麻烦。后来发现周边做后端、做运维的同事压测基本都用Jmeter。Apache Jmeter作为开源压力测试工具Java环境一装就能跑支持HTTP、JDBC、JMS、FTP等主流协议图形界面配好脚本命令行一发就是一份带图表的结果报告。这篇文章就把我从零开始用Jmeter做压力测试的完整路径写出来从环境准备到脚本设计从参数化、连数据库再到结果分析和排坑适合刚接触压测的测试、开发、运维同学照着做。1. 压测前必须想清楚的几件事Jmeter能做什么不能做什么1.1 Jmeter在压力测试生态里的位置Jmeter是Apache Software Foundation维护的纯Java桌面应用核心机制用一句话概括用线程模拟虚拟用户按照你设定的并发数量、循环次数和节奏向目标服务持续发起协议请求然后汇总响应时间、吞吐量、错误率等指标。它的定位是协议级压测工具不是浏览器性能工具。它能精确控制每秒发多少请求但不会去解析JavaScript、渲染CSS所以如果你想测的是用户打开页面到底慢在哪里那是Playwright、Selenium这类浏览器自动化工具的活Jmeter管不了。实际项目里Jmeter最常见的三个用途接口压力测试比如登录、下单、查询、数据库压力测试通过JDBC直接压SQL、混合场景稳定性测试用多个线程组模拟不同业务同时发生。我自己做过的项目里用Jmeter测HTTP接口最多其次就是拿它做MySQL慢查询压测。1.2 压力测试和性能测试的区别很多刚接触的人会把这两个词混在一起。性能测试是验证系统在当前预期负载下表现是否符合要求压力测试是不断加压直到系统崩溃找到它的极限在哪里。用开车的例子类比性能测试是看这辆车在满载5个人、跑120码时油耗多少、噪音多大压力测试是看油门踩到底、连续开两个小时发动机会不会过热、轮胎会不会爆。Jmeter两者都能做主要差别在场景设计性能测试的并发数来自业务预估比如高峰期同时在线1万人估算每秒有500个下单请求压力测试则从能接受的响应时间阈值出发比如要求P95响应小于500ms就逐步从100并发加到500并发找到响应时间拐点。压测前必须先定义清楚这次要回答的问题是验证系统容量还是测试稳定性还是摸清瓶颈在哪。目标不同线程组设计、压测时长、结果分析方式都不同。1.3 压测前的目标拆解我建议在写脚本之前先回答三个问题压什么单接口还是核心链路如果是核心链路登录、查询、下单要用不同线程组分别建模。压多少目标TPS是多少最大并发预估多少没有目标就谈不上压过了没有。看什么主要看吞吐量、响应时间分布还是错误率结果里哪一项不达标需要被接受以我这次压下单接口为例业务方给出的指标是单机支持200并发P95响应时间小于800ms错误率小于0.1%。有了这个基线后面脚本设计、指标判断就都有了标尺而不是跑完一堆数据不知道该怎么评价。2. 环境准备下载、JDK、目录结构和第一次启动2.1 版本选型和JDK对应关系Jmeter是Java写的所以第一件事是确认JDK版本。目前Jmeter 5.x系列要求JDK 8以上官方说支持到JDK 21但如果你要兼容一些老插件JDK 8仍然是最稳的选择。我自己用的Jmeter 5.6.3搭配JDK 11跑常规HTTP和JDBC脚本完全没问题。下载建议直接去官网或国内高校镜像站。搜索引擎里搜jmeter下载很容易点进第三方下载站那些“一键安装版”经常捆了一堆广告软件解压出来还多了不少不认识的东西。官网下载zip包解压即用Windows和macOS/Linux都是同一个包只是启动脚本不同。2.2 目录结构不搞清楚后面插件必踩坑Jmeter解压后的目录结构有几个必须知道的bin/启动脚本Windows用jmeter.batmacOS/Linux用jmeter.sh、核心配置文件jmeter.properties、Jmeter自身日志jmeter.log。lib/Jmeter运行依赖的jar包。你后边要连MySQL把mysql-connector-java-x.x.xx.jar丢到这里重启Jmeter才能生效。lib/ext/扩展插件目录比如JSON断言插件、MQTT插件、PerfMon服务器性能监控插件都放这里。有个很典型的坑放完驱动jar不重启JDBC请求报Cannot load JDBC driver class面上看是驱动找不到实际就是ClassPath没刷新。这个下面JDBC章节还会仔细讲。2.3 首次启动字体、语言和界面看一眼就明白的树形结构Windows双击jmeter.batmacOS或Linux在终端执行sh jmeter.sh。注意启动后会先弹一个黑色命令行窗口很多人以为是启动失败就给关了其实那是Jmeter的运行窗口关掉它Jmeter就退出了。启动完成后如果界面字体特别小特别是高分屏笔记本上修改bin/jmeter.properties里的几个配置# 界面语言 languagezh_CN # 编辑区域字号 jsyntaxtextarea.font.size18 # 高分屏适配 jmeter.hidpi.modetrue jmeter.hidpi.scale.factor2.0修改后重启Jmeter。界面左侧是测试计划树形结构核心逻辑就是从测试计划出发添加线程组在线程组下加取样器、断言、监听器。可以把每个取样器理解成一个发请求的动作线程组是安排多少个人按什么节奏去执行这些动作监听器是记录执行结果的仪表盘。理解这个模型整个Jmeter脚本都是在往这棵树上挂节点。3. 第一个压测脚本的完整搭建从线程组到聚合报告3.1 线程组的三个核心参数线程数、Ramp-Up、循环次数右键测试计划添加线程组。线程组里有几个参数直接决定了压测的形态线程数虚拟用户数。100个线程代表模拟100个并发用户。Ramp-Up时间秒所有线程在多少秒内启动完毕。100个线程、Ramp-Up10表示每秒启动10个线程10秒后全部在线。循环次数每个线程执行脚本的次数。100线程×10次循环1000次请求。调度器配置勾选调度器设置持续时间可以让压测跑固定时长适合稳定性测试。Ramp-Up很值得多说一句。新手容易把它设成0意思就是100个线程瞬间全部打出去这属于脉冲式压测适合测试系统冷启动或雪崩恢复能力但不适合模拟真实用户行为。真实场景里用户是陆续进入页面的所以我一般设置Ramp-Up在10到30秒让服务端的连接池、线程池逐步建立连接。3.2 HTTP请求取样器的配置细节线程组下添加HTTP请求取样器这里填写目标接口的信息协议http或https。服务器名称或IP接口域名或IP。端口号默认80或443非默认端口要填。方法GET、POST等。路径接口路径如/api/order/submit。Parameters/Body DataGET参数填ParametersPOST JSON体填Body Data同时通过HTTP Header Manager添加Content-Type: application/json。参数化放到后面专门讲这里先手工填一个固定参数跑通流程。调试阶段建议再添加一个查看结果树监听器运行后点开请求能看到完整的Request和Response确认参数名、返回格式都对得上。这一步别省脚本没验证正确就直接上量压测结果全是无效请求根本说明不了问题。3.3 监听器选型调试用结果树压测用聚合报告Jmeter的监听器很多实际日常使用两类最核心。查看结果树本质是请求/响应报文的查看器调试阶段看参数传递、返回内容用。它会把每一个请求的报文缓存到内存非常吃资源压测时千万不要带着它跑高并发否则Jmeter本机先成为瓶颈。聚合报告压测结束后看整体统计数据。主要关注以下几列指标含义#Samples总请求数Average平均响应时间msMin / Max最小 / 最大响应时间Std.Dev响应时间标准差越大越不稳定Error%错误请求占比Throughput每秒处理的请求数TPSReceived KB/sec接收速率Avg.Byte平均响应字节数聚合报告里Error%和Throughput是我最先看的两列。错误率超过预期后面所有数据都不能用于容量评估吞吐量上不去再好看的响应时间都没有意义。3.4 命令行模式才是生产级压测的正确姿势GUI模式下运行的压测数据只能作为参考因为Jmeter界面本身、监听器渲染、结果树缓存都在消耗本机资源高并发时会影响结果。真正的线上压测我一般这样操作先关闭图形界面用命令行执行jmeter -n -t login.jmx -l result.jtl -e -o report参数说明-n表示非GUI模式-t指定JMX脚本文件-l保存原始结果数据-e -o指定输出HTML报告的目录。跑完后打开report目录下的index.html能看到吞吐量走势、响应时间分布、活跃线程数等专业图表比GUI里看聚合报告更直观。小规模调试我通常先在GUI里加上查看结果树跑10个并发验证脚本正确然后关掉结果树改用命令行跑200并发正式压测。这个习惯帮我避免了好几次脚本有隐患但没发现压测跑到一半才发现参数不对的尴尬。4. 参数化CSV数据文件和每个线程分块取值到底怎么配4.1 为什么要参数化不参数化的压测结果等于白测压测查询用户详情接口100个线程都带同一个userId1结果会怎样服务端大概率命中缓存或者数据库有缓存响应时间全是1msTPS高得吓人。但这个数据没有参考价值因为它没有真实模拟用户行为。真实场景里100个用户同时查询各自的详情所以压测脚本里的请求参数必须来自一批真实存在的测试数据。Jmeter最常见的做法是CSV Data Set Config把要用的数据放在一个CSV文件里让每个线程从文件里取不同的值。4.2 CSV Data Set Config的每一项配置测试计划下添加CSV Data Set Config各配置项的含义文件名CSV文件的路径建议使用绝对路径或放到bin目录后用相对路径。文件编码UTF-8否则中文数据乱码。变量名称逗号分隔例如userId,password后续脚本用${userId}、${password}引用。分隔符默认英文逗号。是否允许带引号数据如果CSV里有字段值本身包含逗号需要用引号包裹并勾选此项。遇到文件结束符是否循环Recycle on EOF取值True则在文件读完后重新从第一行开始适合长时长压测。遇到文件结束符是否停止线程Stop thread on EOF一般False。Sharing mode共享模式这是一个非常关键的配置展开说。4.3 Sharing mode同一个CSV文件如何让不同线程各取所需Sharing mode有三个选项理解它就能解决jmeter在同一个csv参数化文件中每个线程分块取值这个经典问题。All threads所有线程共享同一个文件游标。线程1取第1行、线程2取第2行依次往下读。这是最常用的模式适合让不同线程拿不同数据数据分散度最好。Current thread group同一个线程组内的线程共享游标不同线程组各自从头取数。适合多个线程组模拟不同业务、各自需要独立数据集的情况。Current thread每个线程维护自己的文件游标从第1行开始独立读取。这样做会让不同线程都从第1行开始看起来好像没用但它结合循环次数就是分块取值的实现方案假设CSV有500行数据你起了100个线程循环5次用Current thread模式每个线程每次循环都从第1行读到第500行配合循环内部的计数器可以做到让线程1只读自己负责的那一段。但在实际压测里我更推荐另一种更可控的做法用计数器函数精确控制每行分配。先保证CSV行数≥线程数Sharing mode选All threads每个线程循环N次就从文件里按顺序取N个不同的值Jmeter会自动让不同线程取到不同行不需要额外计算行号。4.4 参数化使用时的三个常见坑第一CSV文件第一行如果带了表头有些版本会把它当成数据读进去导致第一个请求参数错误。要么去掉表头要么配置忽略首行选项。第二Windows下用Excel编辑CSV保存后往往是ANSI编码Jmeter里如果设置了UTF-8读出来中文就是乱码用记事本另存为UTF-8格式能解决。第三CSV文件路径写错时Jmeter报错不明显脚本跑着跑着变量取到空值。调试阶段在脚本里加一个调试取样器运行后直接看变量有没有正确赋值能省很多排查时间。5. 数据库压测实战JDBC Request查询结果如何传给下一个接口5.1 JDBC Connection Configuration的配置细节很多业务接口的数据不是凭空构造的比如压测订单详情接口需要真实存在的订单号而这些订单号只存在于数据库里。这时候就需要让Jmeter直连数据库取数。测试计划下添加配置元件JDBC Connection Configuration关键配置Variable Name连接池名称比如db_pool。后面JDBC Request要通过这个名称找到它。Database URLjdbc:mysql://192.168.1.100:3306/test_db?useSSLfalsecharacterEncodingutf8serverTimezoneAsia/ShanghaiJDBC Driver classcom.mysql.cj.jdbc.DriverMySQL 8及以上老版本用com.mysql.jdbc.Driver。Username / Password数据库账号密码。连接池的Max Number of Connections默认10如果后面的JDBC查询并发较高要调大这个值否则会报连接等待超时。另外记得把MySQL驱动jar放到lib目录并重启Jmeter。5.2 JDBC Request写法和占位符线程组下添加JDBC Request取样器Variable Name绑定连接池名称填db_pool。Query TypeSelect Statement查询、Update Statement增删改、Callable Statement存储过程。SQL Query直接写SQL语句。Parameter values / Parameter typesSQL里用?占位符这里填对应的值和类型。例如查询前100个用户的IDSELECT id, user_name, phone FROM t_user WHERE status 1 LIMIT 100Query Type选Select StatementVariable Names填userId执行后Jmeter会把结果存成userId_1、userId_2……一系列变量。5.3 把查询结果变成下一个接口参数的完整路径这是热词里jmeter 将jdbc request查询出的数据作为下一个接口的参数的典型场景。假设要通过这100个用户ID去压测用户详情接口思路是第一步在JDBC Request的Variable Names填uid。Jmeter会把查询结果的每一行第一列生成变量uid_1、uid_2一直到uid_100同时生成uid_#表示总行数。第二步添加一个循环控制器循环次数填${uid_#}也就是按查询结果行数循环。第三步循环控制器下加计数器从1开始每次递增1引用名为idx。第四步在HTTP请求的参数值里写${__V(uid_${idx})}。__V函数的作用是先计算里面的变量名uid_1再取出uid_1的值。这样每次循环取一个ID请求参数就是动态的了。这个方法比把100个ID拼成CSV再参数化更省事而且数据来自数据库天然真实。5.4 数据库压测的常见报错连数据库最常见的报错是Cannot load JDBC driver class com.mysql.jdbc.Driver原因就是驱动jar没放对位置或没重启Jmeter。还有Communication link failure说明JDBC URL里的IP端口不通或者数据库防火墙拦了。如果是Connection is not available, request timed out after 30000ms基本是连接池最大连接数填小了调大Max Number of Connections或者降低线程组里的并发数。还有一个关于密码的细节如果数据库密码包含、#这种特殊字符直接写进JDBC URL会导致解析失败。正确做法是在JDBC Connection Configuration的Password字段单独填不要拼到URL里。更安全的做法是用${__P(dbPassword,)}从命令行传入命令加-JdbPasswordxxx避免把生产密码写死在jmx脚本里。6. 让压测脚本真正可用断言、动态Token、文件上传和HTTPS录制6.1 响应断言状态码200不一定代表业务成功压测时如果只看HTTP状态码很容易被误导。接口返回200但业务上可能是用户名或密码错误响应体里是一个错误码。压力测试统计的应该是业务成功请求而不是HTTP层成功。所以在线程组下添加响应断言Field to Test选Response Text。Pattern Matching Rules选Contains。Patterns to Test填业务成功的关键词比如code:0或success。只有同时满足HTTP 200和响应体包含指定关键词请求才算成功。否则Jmeter将请求标记为失败聚合报告的Error%才能真实反映业务失败率。6.2 BeanShell断言的适用场景和脚本写法响应断言只能做包含匹配遇到根据响应里的金额判断是否大于0这种逻辑判断就无能为力了。这时候可以用BeanShell断言在断言里写简单脚本。在线程组下添加BeanShell断言Script框里写String response prev.getResponseDataAsString(); if (response.contains(success) false) { Failure true; FailureMessage 响应中未找到success实际返回 response; }prev是Jmeter提供的对象getResponseDataAsString()拿到完整响应文本。脚本越简单越好因为每个请求都会执行一次逻辑复杂会影响压测本身的性能。如果是新项目我更推荐JSR223断言搭配GroovyJmeter内置Groovy引擎性能和功能都更好。6.3 动态Token提取与防伪标记问题的处理很多系统请求需要携带Token而Token在压测脚本里必须动态获取因为登录一次就会失效。做法是先发一个登录请求用正则表达式提取器从响应里提取Token再通过HTTP Header Manager传给后续请求。假设登录接口返回{token:abc123}正则表达式提取器配置引用名称token正则表达式token:([^])模板$1$匹配数字1后续接口的HTTP Header Manager里添加Authorization: Bearer ${token}即可。热词里提到的jmeter 测试 mvc3项目提示__requestverificationtoken 未提供必要的防伪标记也属于动态Token这一类。ASP.NET MVC开启了防伪验证POST请求必须携带页面生成的__RequestVerificationToken。处理方式是先用GET请求打开表单页面用正则提取器从响应中提取这个隐藏字段的值正则写法类似__RequestVerificationToken typehidden value([^])然后POST时把这个值作为请求参数提交。这类问题归根到底是请求缺少了服务端校验需要的动态标识解决办法都是先从某个前置请求中提取动态值再传给目标请求。6.4 文件上传场景的HTTP请求配置压测上传接口时HTTP请求里需要设置勾选Use multipart/form-data。Files Upload选项卡里填写文件路径本机测试文件路径例如D:/testdata/avatar.jpg参数名称接口约定的文件字段名一般是fileMIME类型image/jpeg或application/octet-stream如果接口还需要业务参数比如上传人的ID在Parameters或Body Data里正常添加。需要注意上传压测会占用大量网络带宽文件太大时压测结果反映的是网络吞吐上限而不是服务端处理能力。我做上传压测时一般准备几KB到几十KB的小文件避免本机带宽先打满。6.5 HTTPS脚本录制代理、证书与录制后的整理接口文档不齐全时可以用录制的方式生成脚本。测试计划下添加HTTP(S)测试脚本录制器端口默认8888然后需要导入Jmeter的CA证书否则HTTPS请求录制时会被拦截。证书路径在bin目录下的ApacheJMeterTemporaryRootCA.crt通过Options SSL Manager导入。同时浏览器或系统代理设置为localhost:8888然后录制器里点击启动浏览器操作一遍页面Jmeter就把所有HTTP/HTTPS请求抓下来了。录制后的脚本通常很乱CSS、JS、图片请求铺天盖地压测时这些静态资源请求全部要删掉只保留业务核心接口。浏览器录制只是帮你快速摸清接口调用关系最终还是要按上面讲的线程组、参数化、断言方式手工整理一遍。7. 结果分析聚合报告里的数字到底在说什么7.1 聚合报告核心指标逐个拆解跑完压测后第一屏看聚合报告但很多新人只盯着Average响应时间这是不够的。我一般是按下面这几个维度去看Average是所有样本的平均响应时间但它会被极端的慢请求拉高不够敏锐。Min和Max看整体范围Max如果特别大说明系统存在偶发的长尾请求。Std.Dev标准差是最容易被忽略也最有价值的一个指标它反映响应时间抖动幅度。平均响应200ms标准差20ms说明系统很稳定平均响应200ms标准差300ms说明虽然有大量请求快但每隔一会儿就有个特别慢的请求拖后腿这时候要去查定时任务、GC或慢SQL。Error%是压测是否有有效的第一道门槛超过预期就直接判负不必再讨论平均响应时间了。Throughput是每秒完成的请求数也就是TPS这个指标直接代表系统的处理能力上限。7.2 百分位响应时间才是用户体感真相平均响应时间会被少数慢请求拉高但用户的实际体验更接近百分位。90% Line表示90%的请求响应时间小于该值95% Line、99% Line同理。Jmeter默认在聚合报告里显示90% Line如果想看95%和99%修改bin/jmeter.propertiesaggregate_runtime_pct190 aggregate_runtime_pct295 aggregate_runtime_pct399性能需求里常说的P95小于500ms指的就是95% Line小于500ms。压测时我一般同时看P95和P99P95反映大多数用户体验P99反映极端情况下的体验。如果P99比P95高出一大截说明系统尾部延迟严重存在明显的抖动源。7.3 结果保存与二次分析查看结果树里单个请求的响应报文可以右键保存Response Data。聚合报告如果要导出做二次分析勾选保存表头数据点击File Save Table Data就可以导出CSV然后用Excel或WPS做透视分析。命令行压测时用-l参数保存的jtl文件是原始数据用-e -o生成HTML报告。报告里的响应时间分布图、TPS曲线、活跃线程数对比比GUI聚合报告更有说服力。特别是TPS曲线如果出现明显下降往往说明服务端触碰到了资源瓶颈。7.4 压测瓶颈定位Jmeter数据之外还要看什么压测结果只能告诉你系统这个时刻慢了、错了不能直接告诉你为什么慢。定位瓶颈需要结合服务端和系统资源监控。这里就涉及一个常见的误区以为压力测试只是Jmeter一个工具的事。事实上服务器CPU、内存、磁盘IO、网络都需要同步监控。CPU压力测试有专门的工具比如Linux下的stress、gpu-burn存储压力测试有fio但它们在压测体系里扮演的角色和Jmeter不同。Jmeter负责制造客户端请求这些工具负责制造服务器硬件层面的负载两者配合才能完整评估系统承载能力。实际操作中我用PerfMon插件采集服务器CPU、内存、磁盘、网络指标或者直接服务器上跑nmon记录。判断思路是如果服务端CPU接近100%说明计算逻辑或SQL执行有问题如果CPU不高但TPS上不去大概率是数据库连接池、服务端线程池配置太小如果响应时间间歇性抖动配合GC日志看看是不是Full GC频繁。7.5 阶梯加压找到系统的拐点一次压测只跑一个固定并发往往找不到系统的真实上限。正确的做法是阶梯式加压从50并发开始跑一轮记录TPS和响应时间再100、200、400、800依次往上加每轮跑够3到5分钟。关注两个关键现象一是TPS随并发数上升而上升到某个点后不再增加甚至下降这个点的TPS就是系统处理能力上限二是响应时间随并发增加开始明显恶化这个点对应的并发数就是系统的承载上限。比如200并发时P95是300ms升到400并发P95变成1200ms那最大建议并发就要控制在300左右。拿到这个数据后线上限流阈值就可以按这个拐点的80%左右来设置留出安全缓冲。8. 压测途中我踩过的坑从报错到定位的完整链路8.1 error writing to server服务端主动断开还是连接池耗尽这个报错我压测时遇到过好几次最典型的一次是压测跑了十分钟后错误率突然从0%飙到60%控制台刷屏java.io.IOException: error writing to server。第一次遇到时我以为是Jmeter所在机器出了问题换了台配置更高的机器重跑问题依旧。后来去服务端看Tomcat日志发现大量Connection reset by peer。这才定位到真正原因服务端最大连接数配的是500Jmeter这边开了1000个线程线程组的keep-alive连接把Tomcat连接池占满了服务端只能主动断开新来的连接。排查链路是这样的先看服务端日志有没有断连记录其次查服务端连接数配置Tomcat的maxThreads、acceptCount最后再看负载均衡或防火墙有没有空闲连接超时。解决方式有几种调大服务端连接数、降低Jmeter并发数或者HTTP请求头里加Connection: close让每个请求独立连接避免长连接占满服务端连接池。另外Jmeter自身的HTTP连接数可以通过bin/jmeter.properties里的httpclient4.max.connections.per.host调大。8.2 “文件已经存在”监听器保存结果的命名冲突报错File ... already exists出现时很多人第一反应是脚本文件被占用其实这个报错多数发生在输出结果文件的场景。我踩过的坑是命令行压测时输出的jtl文件名和上次压测用了同一个Jmeter为了避免覆盖直接报错退出。还有一次是GUI里两个监听器配了同一个输出文件运行时互相抢占文件句柄也是同样的报错。另外CSV参数化文件如果被Excel打开Windows下Jmeter读取时也可能报权限相关错误。解决思路很直接所有输出文件用时间戳命名避免跟历史文件冲突同一份结果只让一个监听器输出参数化文件和结果输出文件不要混在一个目录。我后来写了个简单的启动脚本每次执行前自动创建带日期的输出目录再也没碰过这个报错。8.3 数据库密码特殊字符和连接配置问题连数据库报连接失败时不要只想到账号密码错误先检查JDBC URL的格式。密码里包含、#、这些特殊字符时直接拼在URL里会被当成URL参数分隔符解析。这种问题用Jmeter界面配置看不到报错细节但仔细看异常信息会发现在host解析部分被截断了。另一个MySQL连接常见报错是Public Key Retrieval is not allowed新版MySQL驱动默认要求安全连接连接串里加上allowPublicKeyRetrievaltrueuseSSLfalse能解决。生产数据库密码不要硬编码在jmx文件里用${__P(dbPassword,)}从命令行传脚本文件可以正常提交到代码仓库密码不会泄露。8.4 界面字体、响应中文乱码的调整Jmeter响应结果里中文乱码是压测脚本里很影响判断的小问题。接口返回UTF-8编码但Jmeter有时候按ISO-8859-1解码中文就变成了乱码。最简单的处理是在HTTP请求里设置Content Encodingutf-8如果接口返回的不是UTF-8就改成对应的编码格式。已有脚本不方便逐个改的话可以加一个JSR223后置处理器写一行prev.setDataEncoding(UTF-8)。界面字体大小问题在2.3节已经说过这里补充一个点如果修改jsyntaxtextarea.font.size后没生效确认你改的是bin/jmeter.properties而不是用户目录下覆盖的配置文件。Jmeter启动时会优先读用户目录的配置文件存在两处配置时很容易改错地方。8.5 插件安装的路径需要装插件时用插件管理器最省心。从官方下载plugins-manager.jar放到lib/ext目录重启Jmeter后Options菜单里会出现Plugins Manager在里面可以搜索安装Custom Thread Groups、JSON、MQTT、PerfMon等插件。比如要装MQTT压测插件直接搜索安装Jmeter会自动处理依赖不用手动找jar包。需要注意Jmeter插件本身是开源免费的任何要求付费或破解版的插件网站都不要信。插件安装后如果遇到启动报错检查插件版本和Jmeter版本是否兼容尤其是老版本Jmeter配新插件很容易因为Class版本问题启动失败这时候升级Jmeter版本比折腾插件更省事。压测这个事工具永远是最小的问题。脚本本身要跑得对、数据真实、指标清晰压测结果才有意义。我个人的习惯是任何压测脚本先开10个并发在GUI里跑一遍确认参数、断言、变量取值都正确再关闭GUI用命令行跑正式负载。从50并发开始阶梯加压每轮记录TPS和响应时间找到系统拐点后才算真正摸清承载能力。这套流程跑熟之后后面不管压HTTP接口、数据库还是消息队列核心思路都是一样的。 Jmeter压力测试完整实战指南：从脚本设计到结果分析
上周线上一个下单接口突然变慢用户在群里截图反馈领导丢了一句“压一下看看能扛多少并发”。我当时第一个想到的是LoadRunner但公司没有License装起来也麻烦。后来发现周边做后端、做运维的同事压测基本都用Jmeter。Apache Jmeter作为开源压力测试工具Java环境一装就能跑支持HTTP、JDBC、JMS、FTP等主流协议图形界面配好脚本命令行一发就是一份带图表的结果报告。这篇文章就把我从零开始用Jmeter做压力测试的完整路径写出来从环境准备到脚本设计从参数化、连数据库再到结果分析和排坑适合刚接触压测的测试、开发、运维同学照着做。1. 压测前必须想清楚的几件事Jmeter能做什么不能做什么1.1 Jmeter在压力测试生态里的位置Jmeter是Apache Software Foundation维护的纯Java桌面应用核心机制用一句话概括用线程模拟虚拟用户按照你设定的并发数量、循环次数和节奏向目标服务持续发起协议请求然后汇总响应时间、吞吐量、错误率等指标。它的定位是协议级压测工具不是浏览器性能工具。它能精确控制每秒发多少请求但不会去解析JavaScript、渲染CSS所以如果你想测的是用户打开页面到底慢在哪里那是Playwright、Selenium这类浏览器自动化工具的活Jmeter管不了。实际项目里Jmeter最常见的三个用途接口压力测试比如登录、下单、查询、数据库压力测试通过JDBC直接压SQL、混合场景稳定性测试用多个线程组模拟不同业务同时发生。我自己做过的项目里用Jmeter测HTTP接口最多其次就是拿它做MySQL慢查询压测。1.2 压力测试和性能测试的区别很多刚接触的人会把这两个词混在一起。性能测试是验证系统在当前预期负载下表现是否符合要求压力测试是不断加压直到系统崩溃找到它的极限在哪里。用开车的例子类比性能测试是看这辆车在满载5个人、跑120码时油耗多少、噪音多大压力测试是看油门踩到底、连续开两个小时发动机会不会过热、轮胎会不会爆。Jmeter两者都能做主要差别在场景设计性能测试的并发数来自业务预估比如高峰期同时在线1万人估算每秒有500个下单请求压力测试则从能接受的响应时间阈值出发比如要求P95响应小于500ms就逐步从100并发加到500并发找到响应时间拐点。压测前必须先定义清楚这次要回答的问题是验证系统容量还是测试稳定性还是摸清瓶颈在哪。目标不同线程组设计、压测时长、结果分析方式都不同。1.3 压测前的目标拆解我建议在写脚本之前先回答三个问题压什么单接口还是核心链路如果是核心链路登录、查询、下单要用不同线程组分别建模。压多少目标TPS是多少最大并发预估多少没有目标就谈不上压过了没有。看什么主要看吞吐量、响应时间分布还是错误率结果里哪一项不达标需要被接受以我这次压下单接口为例业务方给出的指标是单机支持200并发P95响应时间小于800ms错误率小于0.1%。有了这个基线后面脚本设计、指标判断就都有了标尺而不是跑完一堆数据不知道该怎么评价。2. 环境准备下载、JDK、目录结构和第一次启动2.1 版本选型和JDK对应关系Jmeter是Java写的所以第一件事是确认JDK版本。目前Jmeter 5.x系列要求JDK 8以上官方说支持到JDK 21但如果你要兼容一些老插件JDK 8仍然是最稳的选择。我自己用的Jmeter 5.6.3搭配JDK 11跑常规HTTP和JDBC脚本完全没问题。下载建议直接去官网或国内高校镜像站。搜索引擎里搜jmeter下载很容易点进第三方下载站那些“一键安装版”经常捆了一堆广告软件解压出来还多了不少不认识的东西。官网下载zip包解压即用Windows和macOS/Linux都是同一个包只是启动脚本不同。2.2 目录结构不搞清楚后面插件必踩坑Jmeter解压后的目录结构有几个必须知道的bin/启动脚本Windows用jmeter.batmacOS/Linux用jmeter.sh、核心配置文件jmeter.properties、Jmeter自身日志jmeter.log。lib/Jmeter运行依赖的jar包。你后边要连MySQL把mysql-connector-java-x.x.xx.jar丢到这里重启Jmeter才能生效。lib/ext/扩展插件目录比如JSON断言插件、MQTT插件、PerfMon服务器性能监控插件都放这里。有个很典型的坑放完驱动jar不重启JDBC请求报Cannot load JDBC driver class面上看是驱动找不到实际就是ClassPath没刷新。这个下面JDBC章节还会仔细讲。2.3 首次启动字体、语言和界面看一眼就明白的树形结构Windows双击jmeter.batmacOS或Linux在终端执行sh jmeter.sh。注意启动后会先弹一个黑色命令行窗口很多人以为是启动失败就给关了其实那是Jmeter的运行窗口关掉它Jmeter就退出了。启动完成后如果界面字体特别小特别是高分屏笔记本上修改bin/jmeter.properties里的几个配置# 界面语言 languagezh_CN # 编辑区域字号 jsyntaxtextarea.font.size18 # 高分屏适配 jmeter.hidpi.modetrue jmeter.hidpi.scale.factor2.0修改后重启Jmeter。界面左侧是测试计划树形结构核心逻辑就是从测试计划出发添加线程组在线程组下加取样器、断言、监听器。可以把每个取样器理解成一个发请求的动作线程组是安排多少个人按什么节奏去执行这些动作监听器是记录执行结果的仪表盘。理解这个模型整个Jmeter脚本都是在往这棵树上挂节点。3. 第一个压测脚本的完整搭建从线程组到聚合报告3.1 线程组的三个核心参数线程数、Ramp-Up、循环次数右键测试计划添加线程组。线程组里有几个参数直接决定了压测的形态线程数虚拟用户数。100个线程代表模拟100个并发用户。Ramp-Up时间秒所有线程在多少秒内启动完毕。100个线程、Ramp-Up10表示每秒启动10个线程10秒后全部在线。循环次数每个线程执行脚本的次数。100线程×10次循环1000次请求。调度器配置勾选调度器设置持续时间可以让压测跑固定时长适合稳定性测试。Ramp-Up很值得多说一句。新手容易把它设成0意思就是100个线程瞬间全部打出去这属于脉冲式压测适合测试系统冷启动或雪崩恢复能力但不适合模拟真实用户行为。真实场景里用户是陆续进入页面的所以我一般设置Ramp-Up在10到30秒让服务端的连接池、线程池逐步建立连接。3.2 HTTP请求取样器的配置细节线程组下添加HTTP请求取样器这里填写目标接口的信息协议http或https。服务器名称或IP接口域名或IP。端口号默认80或443非默认端口要填。方法GET、POST等。路径接口路径如/api/order/submit。Parameters/Body DataGET参数填ParametersPOST JSON体填Body Data同时通过HTTP Header Manager添加Content-Type: application/json。参数化放到后面专门讲这里先手工填一个固定参数跑通流程。调试阶段建议再添加一个查看结果树监听器运行后点开请求能看到完整的Request和Response确认参数名、返回格式都对得上。这一步别省脚本没验证正确就直接上量压测结果全是无效请求根本说明不了问题。3.3 监听器选型调试用结果树压测用聚合报告Jmeter的监听器很多实际日常使用两类最核心。查看结果树本质是请求/响应报文的查看器调试阶段看参数传递、返回内容用。它会把每一个请求的报文缓存到内存非常吃资源压测时千万不要带着它跑高并发否则Jmeter本机先成为瓶颈。聚合报告压测结束后看整体统计数据。主要关注以下几列指标含义#Samples总请求数Average平均响应时间msMin / Max最小 / 最大响应时间Std.Dev响应时间标准差越大越不稳定Error%错误请求占比Throughput每秒处理的请求数TPSReceived KB/sec接收速率Avg.Byte平均响应字节数聚合报告里Error%和Throughput是我最先看的两列。错误率超过预期后面所有数据都不能用于容量评估吞吐量上不去再好看的响应时间都没有意义。3.4 命令行模式才是生产级压测的正确姿势GUI模式下运行的压测数据只能作为参考因为Jmeter界面本身、监听器渲染、结果树缓存都在消耗本机资源高并发时会影响结果。真正的线上压测我一般这样操作先关闭图形界面用命令行执行jmeter -n -t login.jmx -l result.jtl -e -o report参数说明-n表示非GUI模式-t指定JMX脚本文件-l保存原始结果数据-e -o指定输出HTML报告的目录。跑完后打开report目录下的index.html能看到吞吐量走势、响应时间分布、活跃线程数等专业图表比GUI里看聚合报告更直观。小规模调试我通常先在GUI里加上查看结果树跑10个并发验证脚本正确然后关掉结果树改用命令行跑200并发正式压测。这个习惯帮我避免了好几次脚本有隐患但没发现压测跑到一半才发现参数不对的尴尬。4. 参数化CSV数据文件和每个线程分块取值到底怎么配4.1 为什么要参数化不参数化的压测结果等于白测压测查询用户详情接口100个线程都带同一个userId1结果会怎样服务端大概率命中缓存或者数据库有缓存响应时间全是1msTPS高得吓人。但这个数据没有参考价值因为它没有真实模拟用户行为。真实场景里100个用户同时查询各自的详情所以压测脚本里的请求参数必须来自一批真实存在的测试数据。Jmeter最常见的做法是CSV Data Set Config把要用的数据放在一个CSV文件里让每个线程从文件里取不同的值。4.2 CSV Data Set Config的每一项配置测试计划下添加CSV Data Set Config各配置项的含义文件名CSV文件的路径建议使用绝对路径或放到bin目录后用相对路径。文件编码UTF-8否则中文数据乱码。变量名称逗号分隔例如userId,password后续脚本用${userId}、${password}引用。分隔符默认英文逗号。是否允许带引号数据如果CSV里有字段值本身包含逗号需要用引号包裹并勾选此项。遇到文件结束符是否循环Recycle on EOF取值True则在文件读完后重新从第一行开始适合长时长压测。遇到文件结束符是否停止线程Stop thread on EOF一般False。Sharing mode共享模式这是一个非常关键的配置展开说。4.3 Sharing mode同一个CSV文件如何让不同线程各取所需Sharing mode有三个选项理解它就能解决jmeter在同一个csv参数化文件中每个线程分块取值这个经典问题。All threads所有线程共享同一个文件游标。线程1取第1行、线程2取第2行依次往下读。这是最常用的模式适合让不同线程拿不同数据数据分散度最好。Current thread group同一个线程组内的线程共享游标不同线程组各自从头取数。适合多个线程组模拟不同业务、各自需要独立数据集的情况。Current thread每个线程维护自己的文件游标从第1行开始独立读取。这样做会让不同线程都从第1行开始看起来好像没用但它结合循环次数就是分块取值的实现方案假设CSV有500行数据你起了100个线程循环5次用Current thread模式每个线程每次循环都从第1行读到第500行配合循环内部的计数器可以做到让线程1只读自己负责的那一段。但在实际压测里我更推荐另一种更可控的做法用计数器函数精确控制每行分配。先保证CSV行数≥线程数Sharing mode选All threads每个线程循环N次就从文件里按顺序取N个不同的值Jmeter会自动让不同线程取到不同行不需要额外计算行号。4.4 参数化使用时的三个常见坑第一CSV文件第一行如果带了表头有些版本会把它当成数据读进去导致第一个请求参数错误。要么去掉表头要么配置忽略首行选项。第二Windows下用Excel编辑CSV保存后往往是ANSI编码Jmeter里如果设置了UTF-8读出来中文就是乱码用记事本另存为UTF-8格式能解决。第三CSV文件路径写错时Jmeter报错不明显脚本跑着跑着变量取到空值。调试阶段在脚本里加一个调试取样器运行后直接看变量有没有正确赋值能省很多排查时间。5. 数据库压测实战JDBC Request查询结果如何传给下一个接口5.1 JDBC Connection Configuration的配置细节很多业务接口的数据不是凭空构造的比如压测订单详情接口需要真实存在的订单号而这些订单号只存在于数据库里。这时候就需要让Jmeter直连数据库取数。测试计划下添加配置元件JDBC Connection Configuration关键配置Variable Name连接池名称比如db_pool。后面JDBC Request要通过这个名称找到它。Database URLjdbc:mysql://192.168.1.100:3306/test_db?useSSLfalsecharacterEncodingutf8serverTimezoneAsia/ShanghaiJDBC Driver classcom.mysql.cj.jdbc.DriverMySQL 8及以上老版本用com.mysql.jdbc.Driver。Username / Password数据库账号密码。连接池的Max Number of Connections默认10如果后面的JDBC查询并发较高要调大这个值否则会报连接等待超时。另外记得把MySQL驱动jar放到lib目录并重启Jmeter。5.2 JDBC Request写法和占位符线程组下添加JDBC Request取样器Variable Name绑定连接池名称填db_pool。Query TypeSelect Statement查询、Update Statement增删改、Callable Statement存储过程。SQL Query直接写SQL语句。Parameter values / Parameter typesSQL里用?占位符这里填对应的值和类型。例如查询前100个用户的IDSELECT id, user_name, phone FROM t_user WHERE status 1 LIMIT 100Query Type选Select StatementVariable Names填userId执行后Jmeter会把结果存成userId_1、userId_2……一系列变量。5.3 把查询结果变成下一个接口参数的完整路径这是热词里jmeter 将jdbc request查询出的数据作为下一个接口的参数的典型场景。假设要通过这100个用户ID去压测用户详情接口思路是第一步在JDBC Request的Variable Names填uid。Jmeter会把查询结果的每一行第一列生成变量uid_1、uid_2一直到uid_100同时生成uid_#表示总行数。第二步添加一个循环控制器循环次数填${uid_#}也就是按查询结果行数循环。第三步循环控制器下加计数器从1开始每次递增1引用名为idx。第四步在HTTP请求的参数值里写${__V(uid_${idx})}。__V函数的作用是先计算里面的变量名uid_1再取出uid_1的值。这样每次循环取一个ID请求参数就是动态的了。这个方法比把100个ID拼成CSV再参数化更省事而且数据来自数据库天然真实。5.4 数据库压测的常见报错连数据库最常见的报错是Cannot load JDBC driver class com.mysql.jdbc.Driver原因就是驱动jar没放对位置或没重启Jmeter。还有Communication link failure说明JDBC URL里的IP端口不通或者数据库防火墙拦了。如果是Connection is not available, request timed out after 30000ms基本是连接池最大连接数填小了调大Max Number of Connections或者降低线程组里的并发数。还有一个关于密码的细节如果数据库密码包含、#这种特殊字符直接写进JDBC URL会导致解析失败。正确做法是在JDBC Connection Configuration的Password字段单独填不要拼到URL里。更安全的做法是用${__P(dbPassword,)}从命令行传入命令加-JdbPasswordxxx避免把生产密码写死在jmx脚本里。6. 让压测脚本真正可用断言、动态Token、文件上传和HTTPS录制6.1 响应断言状态码200不一定代表业务成功压测时如果只看HTTP状态码很容易被误导。接口返回200但业务上可能是用户名或密码错误响应体里是一个错误码。压力测试统计的应该是业务成功请求而不是HTTP层成功。所以在线程组下添加响应断言Field to Test选Response Text。Pattern Matching Rules选Contains。Patterns to Test填业务成功的关键词比如code:0或success。只有同时满足HTTP 200和响应体包含指定关键词请求才算成功。否则Jmeter将请求标记为失败聚合报告的Error%才能真实反映业务失败率。6.2 BeanShell断言的适用场景和脚本写法响应断言只能做包含匹配遇到根据响应里的金额判断是否大于0这种逻辑判断就无能为力了。这时候可以用BeanShell断言在断言里写简单脚本。在线程组下添加BeanShell断言Script框里写String response prev.getResponseDataAsString(); if (response.contains(success) false) { Failure true; FailureMessage 响应中未找到success实际返回 response; }prev是Jmeter提供的对象getResponseDataAsString()拿到完整响应文本。脚本越简单越好因为每个请求都会执行一次逻辑复杂会影响压测本身的性能。如果是新项目我更推荐JSR223断言搭配GroovyJmeter内置Groovy引擎性能和功能都更好。6.3 动态Token提取与防伪标记问题的处理很多系统请求需要携带Token而Token在压测脚本里必须动态获取因为登录一次就会失效。做法是先发一个登录请求用正则表达式提取器从响应里提取Token再通过HTTP Header Manager传给后续请求。假设登录接口返回{token:abc123}正则表达式提取器配置引用名称token正则表达式token:([^])模板$1$匹配数字1后续接口的HTTP Header Manager里添加Authorization: Bearer ${token}即可。热词里提到的jmeter 测试 mvc3项目提示__requestverificationtoken 未提供必要的防伪标记也属于动态Token这一类。ASP.NET MVC开启了防伪验证POST请求必须携带页面生成的__RequestVerificationToken。处理方式是先用GET请求打开表单页面用正则提取器从响应中提取这个隐藏字段的值正则写法类似__RequestVerificationToken typehidden value([^])然后POST时把这个值作为请求参数提交。这类问题归根到底是请求缺少了服务端校验需要的动态标识解决办法都是先从某个前置请求中提取动态值再传给目标请求。6.4 文件上传场景的HTTP请求配置压测上传接口时HTTP请求里需要设置勾选Use multipart/form-data。Files Upload选项卡里填写文件路径本机测试文件路径例如D:/testdata/avatar.jpg参数名称接口约定的文件字段名一般是fileMIME类型image/jpeg或application/octet-stream如果接口还需要业务参数比如上传人的ID在Parameters或Body Data里正常添加。需要注意上传压测会占用大量网络带宽文件太大时压测结果反映的是网络吞吐上限而不是服务端处理能力。我做上传压测时一般准备几KB到几十KB的小文件避免本机带宽先打满。6.5 HTTPS脚本录制代理、证书与录制后的整理接口文档不齐全时可以用录制的方式生成脚本。测试计划下添加HTTP(S)测试脚本录制器端口默认8888然后需要导入Jmeter的CA证书否则HTTPS请求录制时会被拦截。证书路径在bin目录下的ApacheJMeterTemporaryRootCA.crt通过Options SSL Manager导入。同时浏览器或系统代理设置为localhost:8888然后录制器里点击启动浏览器操作一遍页面Jmeter就把所有HTTP/HTTPS请求抓下来了。录制后的脚本通常很乱CSS、JS、图片请求铺天盖地压测时这些静态资源请求全部要删掉只保留业务核心接口。浏览器录制只是帮你快速摸清接口调用关系最终还是要按上面讲的线程组、参数化、断言方式手工整理一遍。7. 结果分析聚合报告里的数字到底在说什么7.1 聚合报告核心指标逐个拆解跑完压测后第一屏看聚合报告但很多新人只盯着Average响应时间这是不够的。我一般是按下面这几个维度去看Average是所有样本的平均响应时间但它会被极端的慢请求拉高不够敏锐。Min和Max看整体范围Max如果特别大说明系统存在偶发的长尾请求。Std.Dev标准差是最容易被忽略也最有价值的一个指标它反映响应时间抖动幅度。平均响应200ms标准差20ms说明系统很稳定平均响应200ms标准差300ms说明虽然有大量请求快但每隔一会儿就有个特别慢的请求拖后腿这时候要去查定时任务、GC或慢SQL。Error%是压测是否有有效的第一道门槛超过预期就直接判负不必再讨论平均响应时间了。Throughput是每秒完成的请求数也就是TPS这个指标直接代表系统的处理能力上限。7.2 百分位响应时间才是用户体感真相平均响应时间会被少数慢请求拉高但用户的实际体验更接近百分位。90% Line表示90%的请求响应时间小于该值95% Line、99% Line同理。Jmeter默认在聚合报告里显示90% Line如果想看95%和99%修改bin/jmeter.propertiesaggregate_runtime_pct190 aggregate_runtime_pct295 aggregate_runtime_pct399性能需求里常说的P95小于500ms指的就是95% Line小于500ms。压测时我一般同时看P95和P99P95反映大多数用户体验P99反映极端情况下的体验。如果P99比P95高出一大截说明系统尾部延迟严重存在明显的抖动源。7.3 结果保存与二次分析查看结果树里单个请求的响应报文可以右键保存Response Data。聚合报告如果要导出做二次分析勾选保存表头数据点击File Save Table Data就可以导出CSV然后用Excel或WPS做透视分析。命令行压测时用-l参数保存的jtl文件是原始数据用-e -o生成HTML报告。报告里的响应时间分布图、TPS曲线、活跃线程数对比比GUI聚合报告更有说服力。特别是TPS曲线如果出现明显下降往往说明服务端触碰到了资源瓶颈。7.4 压测瓶颈定位Jmeter数据之外还要看什么压测结果只能告诉你系统这个时刻慢了、错了不能直接告诉你为什么慢。定位瓶颈需要结合服务端和系统资源监控。这里就涉及一个常见的误区以为压力测试只是Jmeter一个工具的事。事实上服务器CPU、内存、磁盘IO、网络都需要同步监控。CPU压力测试有专门的工具比如Linux下的stress、gpu-burn存储压力测试有fio但它们在压测体系里扮演的角色和Jmeter不同。Jmeter负责制造客户端请求这些工具负责制造服务器硬件层面的负载两者配合才能完整评估系统承载能力。实际操作中我用PerfMon插件采集服务器CPU、内存、磁盘、网络指标或者直接服务器上跑nmon记录。判断思路是如果服务端CPU接近100%说明计算逻辑或SQL执行有问题如果CPU不高但TPS上不去大概率是数据库连接池、服务端线程池配置太小如果响应时间间歇性抖动配合GC日志看看是不是Full GC频繁。7.5 阶梯加压找到系统的拐点一次压测只跑一个固定并发往往找不到系统的真实上限。正确的做法是阶梯式加压从50并发开始跑一轮记录TPS和响应时间再100、200、400、800依次往上加每轮跑够3到5分钟。关注两个关键现象一是TPS随并发数上升而上升到某个点后不再增加甚至下降这个点的TPS就是系统处理能力上限二是响应时间随并发增加开始明显恶化这个点对应的并发数就是系统的承载上限。比如200并发时P95是300ms升到400并发P95变成1200ms那最大建议并发就要控制在300左右。拿到这个数据后线上限流阈值就可以按这个拐点的80%左右来设置留出安全缓冲。8. 压测途中我踩过的坑从报错到定位的完整链路8.1 error writing to server服务端主动断开还是连接池耗尽这个报错我压测时遇到过好几次最典型的一次是压测跑了十分钟后错误率突然从0%飙到60%控制台刷屏java.io.IOException: error writing to server。第一次遇到时我以为是Jmeter所在机器出了问题换了台配置更高的机器重跑问题依旧。后来去服务端看Tomcat日志发现大量Connection reset by peer。这才定位到真正原因服务端最大连接数配的是500Jmeter这边开了1000个线程线程组的keep-alive连接把Tomcat连接池占满了服务端只能主动断开新来的连接。排查链路是这样的先看服务端日志有没有断连记录其次查服务端连接数配置Tomcat的maxThreads、acceptCount最后再看负载均衡或防火墙有没有空闲连接超时。解决方式有几种调大服务端连接数、降低Jmeter并发数或者HTTP请求头里加Connection: close让每个请求独立连接避免长连接占满服务端连接池。另外Jmeter自身的HTTP连接数可以通过bin/jmeter.properties里的httpclient4.max.connections.per.host调大。8.2 “文件已经存在”监听器保存结果的命名冲突报错File ... already exists出现时很多人第一反应是脚本文件被占用其实这个报错多数发生在输出结果文件的场景。我踩过的坑是命令行压测时输出的jtl文件名和上次压测用了同一个Jmeter为了避免覆盖直接报错退出。还有一次是GUI里两个监听器配了同一个输出文件运行时互相抢占文件句柄也是同样的报错。另外CSV参数化文件如果被Excel打开Windows下Jmeter读取时也可能报权限相关错误。解决思路很直接所有输出文件用时间戳命名避免跟历史文件冲突同一份结果只让一个监听器输出参数化文件和结果输出文件不要混在一个目录。我后来写了个简单的启动脚本每次执行前自动创建带日期的输出目录再也没碰过这个报错。8.3 数据库密码特殊字符和连接配置问题连数据库报连接失败时不要只想到账号密码错误先检查JDBC URL的格式。密码里包含、#、这些特殊字符时直接拼在URL里会被当成URL参数分隔符解析。这种问题用Jmeter界面配置看不到报错细节但仔细看异常信息会发现在host解析部分被截断了。另一个MySQL连接常见报错是Public Key Retrieval is not allowed新版MySQL驱动默认要求安全连接连接串里加上allowPublicKeyRetrievaltrueuseSSLfalse能解决。生产数据库密码不要硬编码在jmx文件里用${__P(dbPassword,)}从命令行传脚本文件可以正常提交到代码仓库密码不会泄露。8.4 界面字体、响应中文乱码的调整Jmeter响应结果里中文乱码是压测脚本里很影响判断的小问题。接口返回UTF-8编码但Jmeter有时候按ISO-8859-1解码中文就变成了乱码。最简单的处理是在HTTP请求里设置Content Encodingutf-8如果接口返回的不是UTF-8就改成对应的编码格式。已有脚本不方便逐个改的话可以加一个JSR223后置处理器写一行prev.setDataEncoding(UTF-8)。界面字体大小问题在2.3节已经说过这里补充一个点如果修改jsyntaxtextarea.font.size后没生效确认你改的是bin/jmeter.properties而不是用户目录下覆盖的配置文件。Jmeter启动时会优先读用户目录的配置文件存在两处配置时很容易改错地方。8.5 插件安装的路径需要装插件时用插件管理器最省心。从官方下载plugins-manager.jar放到lib/ext目录重启Jmeter后Options菜单里会出现Plugins Manager在里面可以搜索安装Custom Thread Groups、JSON、MQTT、PerfMon等插件。比如要装MQTT压测插件直接搜索安装Jmeter会自动处理依赖不用手动找jar包。需要注意Jmeter插件本身是开源免费的任何要求付费或破解版的插件网站都不要信。插件安装后如果遇到启动报错检查插件版本和Jmeter版本是否兼容尤其是老版本Jmeter配新插件很容易因为Class版本问题启动失败这时候升级Jmeter版本比折腾插件更省事。压测这个事工具永远是最小的问题。脚本本身要跑得对、数据真实、指标清晰压测结果才有意义。我个人的习惯是任何压测脚本先开10个并发在GUI里跑一遍确认参数、断言、变量取值都正确再关闭GUI用命令行跑正式负载。从50并发开始阶梯加压每轮记录TPS和响应时间找到系统拐点后才算真正摸清承载能力。这套流程跑熟之后后面不管压HTTP接口、数据库还是消息队列核心思路都是一样的。