做性能压测这几年JMeter是我用得最多、也是踩坑最深的工具。最近正好帮朋友处理了一个迁移项目整套微服务环境从单节点迁移到云上ECS之后要用JMeter跑高并发脚本验证云上承载能力。借着这个机会我把JMeter从安装配置、脚本编写、参数化、断言、高并发模拟到常见报错排查的完整流程重新梳理了一遍整理成这篇教程希望能帮刚开始接触JMeter的同学少走弯路。这篇教程不打算按官方文档的目录顺序平铺直叙而是按照我实际做压测时的工作流来讲先讲环境怎么搭再讲怎么录制和编写脚本然后讲参数化和断言怎么让脚本真正可用接着讲高并发压测怎么跑、报告怎么看最后专门列一节常见报错和排查记录。每个环节我都会把当时为什么要这么做的原因讲明白也会把容易踩的坑标出来。1. 环境准备与基础安装1.1 下载JDK与JMeter的版本对应关系很多人下载JMeter之后双击启动脚本没反应第一反应是JMeter坏了其实多半是JDK没装对。JMeter本身是纯Java应用它的运行完全依赖JDK提供的基础运行环境JDK版本不匹配会导致各种莫名其妙的问题比如控制台一闪而过、GUI起不来、或者运行时报UnsupportedClassVersionError。我建议的JDK版本选择逻辑是这样的JMeter 5.6.x对应JDK 8以上JMeter 5.5对应JDK 8或JDK 11JMeter 4.0及以下版本最好使用JDK 8。在实际项目中我常用JMeter 5.4.1配JDK 1.8这个组合在Windows和Linux上都很稳定网上资料也多遇到问题容易搜到解决方案。安装JDK时的记住两点一是环境变量JAVA_HOME要指向JDK安装目录而不是之前的JRE目录PATH里也要加上%JAVA_HOME%\bin二是在命令行里执行java -version确认版本号这是最快、最可靠的验证方式。有的机器上装了多个JDK版本需要检查PATH顺序是否正确否则命令行里看到的版本和实际被调用的版本可能不是同一个。1.2 下载JMeter安装包并完成初始配置JMeter官方下载地址是jmeter.apache.org从官网首页的Download页面选择Binary版本也就是zip或tgz压缩包。注意不要下载Source版本那是源码包需要手动编译对普通使用者来说没意义。Windows环境下下载zip包后直接解压到一个不含空格的目录比如D:\apache-jmeter-5.4.1。解压后进入bin目录双击jmeter.bat即可启动GUI。如果双击后一闪而过多半是JAVA_HOME配置有问题回到命令行里cd到bin目录直接敲jmeter.bat这样错误信息会留在窗口里方便定位。Linux服务器上安装更简单不需要GUI只需要把zip包解压到指定目录然后修改bin目录下jmeter脚本的可执行权限之后就可以用jmeter -n -t脚本名.jmx -l结果.jtl的方式命令行压测了。注意JMeter是纯Java程序不依赖MySQL、Tomcat之类的服务。但是如果你要测试数据库接口需要在JMeter的lib目录下放对应的JDBC驱动包这点后面讲数据库参数化的时候会细说。1.3 调整界面字体大小与语言刚打开JMeter时默认界面字体很小在高分辨率屏幕上看起来特别费劲。调字体有两个地方一个是在JMeter界面里点击“选项”菜单下的“外观”选择一个合适的主题有的主题字体相对大一些另一个更彻底的办法是修改bin目录下的jmeter.properties文件找到jsyntaxtextarea.font.size这个配置项把默认值改大比如改成22保存后重启JMeter。语言方面JMeter默认跟随系统语言和locale。如果你想固定使用中文界面同样在jmeter.properties里找到languageen改成languagezh_CN这样每次打开都是中文。不过我个人实际使用中更倾向于保持英文界面因为网上大部分教程和Stack Overflow的问答、日志报错都是英文中英文对照着看反而更容易理解。1.4 安装插件管理器与常用插件JMeter原生功能虽然强大但有些高级场景需要装插件。最常见的是MQTT压测需要用MQTT插件来模拟物联网设备的消息收发还有自定义线程组插件用来模拟更复杂的并发模型比如每秒固定启动多少个线程。插件管理器本身也是一个插件但它是其他插件的入口。安装方式从插件管理器的GitHub仓库下载jmeter-plugins-manager.jar文件放到JMeter安装目录的lib/ext目录下重启JMeter。重启后菜单栏会多出“选项”下的“Plugins Manager”入口打开之后就能可视化搜索、安装、卸载各种插件。以MQTT插件为例在插件管理器里切换到“Available Plugins”页签勾选MQTT Sampler相关插件点右下角“Apply Changes and Restart JMeter”JMeter会自动下载依赖并重启。这个过程中需要联网如果网络环境受限插件下载会失败这时候可以手动下载插件jar包放到lib/ext目录下但是要注意插件间依赖关系建议优先用管理器安装。2. 创建第一个测试计划接口测试从0到12.1 线程组设计三个参数的真正含义测试计划是所有脚本的根节点右键点击测试计划添加“线程用户”下面的“线程组”就完成了最基础的一步。线程组是整个压测的入口决定了你会模拟多少用户、以什么节奏发请求。线程组页面上有三个核心参数很多新手把这几个参数理解错了。线程数就是并发的用户数量这个好理解但Ramp-Up Period准备时长的意思是在多少秒内把这么多线程全部启动起来。循环次数表示每个线程执行完一遍业务之后是否继续重复执行。举个例子说明这三个参数怎么配合。要模拟100个用户持续压测10分钟可以设置线程数100Ramp-Up Period为10也就是每秒启动10个线程10秒内100个线程全部就绪循环次数选择“永远”然后在调度器配置里勾选持续时间填600秒。这样就从10秒后开始稳定并发持续10分钟自动结束。如果上来就把100个线程瞬间全部启动且不考虑服务器是否能承受很容易造成瞬时连接风暴压测结果并不能真实反映系统承载能力。我通常设置Ramp-Up时间等于线程数除以预期的每秒启动数比如100线程、每秒10个就是10秒。提示线程组里的“延迟创建线程直到需要”这个选项默认不勾选即可。勾选后会按需创建线程可以模拟更真实的用户到达场景但会让结果更难预测新手阶段不要动这个。2.2 HTTP请求配置与Restful参数写法线程组下面加Sampler选择HTTP请求这里就是写被测接口信息的地方。HTTP请求面板上的核心字段协议http或https、服务器名称或IP、端口号、方法GET、POST、PUT、DELETE等、路径、内容编码、参数列表。Restful风格的接口路径中会带路径参数比如/user/1001这种参数不能放在查询参数里而是直接把路径写成/user/${userId}的形式然后在“用户定义的变量”组件里定义userId的值或者从CSV参数化文件中动态读取。如果是POST请求且提交的是JSON数据比较常见的做法有两种。一种是右键HTTP请求添加“HTTP信息头管理器”在头管理器里添加Content-Type: application/json然后在HTTP请求的“Body Data”里直接写JSON字符串。另一种是直接勾选“Use multipart/form-data”但这种一般用于上传文件。我推荐用第一种JSON格式直观后端也容易解析。查询参数更简单直接填到“参数”表格里第一列参数名第二列参数值JMeter会自动做URL编码。要注意的是接口文档里写明必须传递的参数在脚本里一个都不能漏否则压测出来的错误率不是真实反映系统性能而是反映脚本配置错误。2.3 察看结果树最常用的调试工具脚本写好了但响应对不对、服务器返回了什么总得有个地方看。这就是察看结果树的作用。在HTTP请求上右键添加监听器选择察看结果树。运行一次请求后结果树会列出每个请求的响应结果。面板左上角可以切换查看方式默认是文本可以看HTML也可以用“JSON Path Tester”或者“正则表达式测试器”来从响应里提取字段这个对后面写断言和关联非常有用。查看结果树面板里还可以看到请求数据和响应数据这就像浏览器的开发者工具通过对比请求和响应来定位问题。如果响应结果里显示HTTP状态码200但业务上仍然报错这时候就看响应体里的业务码很多系统的接口即使处理失败HTTP状态码也是200真正的错误信息在业务码里。结果树里的数据要导出的话点面板右上角那个保存按钮可以选中一个请求单独保存响应数据。如果要一次性导出所有请求的结果建议不要拷贝粘贴而是在命令行压测时通过 -l 参数输出jtl结果文件或者在GUI里右键监听器选择“保存表头数据”和“所有数据”生成规整的CSV。2.4 RESTful接口压测时服务器返回防伪令牌问题热搜词里有一条典型的场景测试MVC3项目时提示__RequestVerificationToken未提供必要的防伪标记。这类问题在真实接口压测中很常见尤其是老的项目框架里防伪令牌机制的判断比较简单只校验请求里有没有带这个参数不校验参数对不对这就给压测留了操作空间。解决思路分两步。第一步用察看结果树看第一次请求登录页面的响应从中提取出__RequestVerificationToken对应的值这通常是一个隐藏输入框的值或者是一段Cookie。第二步把提取到的值通过“后置处理器”里的“正则表达式提取器”或者“JSON提取器”存到一个变量里然后在后续的POST请求参数中加上__RequestVerificationToken${token}这样就能绕过防伪校验。如果系统校验比较严格还需要把第一次响应里的Set-Cookie值也通过Cookie管理器保存下来后续请求自动携带。JMeter里添加HTTP Cookie管理器并将它放在线程组下、HTTP请求前面JMeter会自动维护Cookie不需要手动设置。3. 参数化与断言让脚本真正可用3.1 CSV参数化多账号、多数据批量模拟压测时如果所有并发用户都用同一个账号、同一份数据服务端会命中缓存压出来的TPS虚高完全不能反映真实场景。更贴近实际的做法是让每个虚拟用户使用不同的账号、不同的查询条件这就需要参数化。参数化最常用的方案是CSV Data Set Config。在线程组下右键添加配置元件选择CSV Data Set Config。配置项里最重要的是“文件名”和“变量名称”“文件名”填写CSV文件的绝对路径比如/home/test/data.csvCSV文件里一列对应一个字段第一行可以是列名也可以直接是数据根据“变量名称”里定义的名字对应“变量名称”用英文逗号分隔多列。“共享模式”这个设置非常关键。默认是“All threads”即所有线程共享这个CSV文件。如果想实现热搜词里说的“每个线程分块取值”也就是线程1取第1行、线程2取第2行、各自独立不会互相抢占数据就需要把共享模式改成“Current thread group”。这种模式下每个线程有自己独立的光标从CSV文件里按顺序各自取数适合多账号登录的场景。简单总结一下共享模式的取舍点All threads所有线程共用一份数据适合数据量较少、允许重复使用的场景。Current thread group同一个线程组内的线程各自独立取数适合多账号场景。Current thread每个线程独立取数几乎不会冲突但要求CSV文件行数足够多。另外CSV文件最好用UTF-8编码保存避免中文乱码。文件路径上不要有中文和空格Windows环境下路径里的反斜杠要转义可以写相对路径以bin目录为基准。3.2 JDBC参数化数据库查询结果当接口入参除了CSV文件还有一种常见的参数化需求是从数据库里查询数据然后把这些数据作为接口入参。前面说的热搜词“jmeter 数据库参数化取值”“jmeter将jdbc request查询出的数据作为下一个接口的参数”就是这个场景。用JMeter查数据库分两步。第一步添加JDBC Connection Configuration配置元件配置数据库连接URL、JDBC驱动类、用户名、密码。这里要注意驱动类要根据数据库类型来填MySQL是com.mysql.jdbc.DriverMySQL 5.x或com.mysql.cj.jdbc.DriverMySQL 8.x。同时需要把对应的JDBC驱动jar包放到JMeter的lib目录下否则会报找不到驱动类。第二步添加JDBC Request Sampler在SQL Query里写真实查询语句比如SELECT user_id, user_name FROM t_user WHERE status 1 LIMIT 10。在JDBC Request的“Variable Names”里填user_id,user_name这样查询结果就会被存到同名变量里。后续接口请求参数里直接写${user_id_1}、${user_name_1}就能引用查询结果的第一行数据。这里有个细节要注意如果查询返回多行数据通过${user_id_1}、${user_id_2}这种方式依次引用第1行、第2行。如果想一次性把所有行取出来可以在Variable Names里给变量加_0后缀表示全部列数据拼接。实际上我更推荐的做法是只把每行数据存成独立变量然后在循环控制器里按索引逐行取数这样更灵活。数据库参数化比CSV参数化的优势在于数据是实时查询的场景更真实但代价是每次压测前数据库连接配置必须正确且查询耗时会叠加到压测结果里。如果只是要测某几个固定的边界数据用CSV文件就够了如果入参需要从动态数据里选择再考虑JDBC方式。3.3 断言体系响应断言、JSON断言与Beanshell断言压测执行完不能只看HTTP状态码还要验证响应内容是否符合业务预期。这个验证动作就是断言。最常用的是响应断言。在HTTP请求上右键添加断言响应断言。新增一条规则在“测试字段”里选择“响应文本”然后在“模式匹配规则”里选择“包括”填上预期的关键字比如{code:0}或者success就能确保接口的业务逻辑是通的。然后是JSON断言它适合处理JSON格式的响应。新增JSON断言后填一个JSON路径表达式比如$.code期望值填0JMeter会解析响应体并校验这个路径对应值是否等于0。相比响应断言对整个响应文本做包含匹配JSON断言更精准不会因为响应里有其他位置的相同字符串而误判。Beanshell断言是JMeter里灵活性最高的断言方式适合处理复杂的业务逻辑比如要同时判断多个条件或者要做数值比较运算。Beanshell断言里直接写Java代码可以在脚本里访问prev对象、vars对象和log对象。比如判断响应码响应体组合逻辑String responseCode prev.getResponseCode(); if (!200.equals(responseCode)) { Failure true; FailureMessage 响应码错误: responseCode; } else { String responseData prev.getResponseDataAsString(); if (responseData.contains(error) responseData.contains(500)) { Failure true; FailureMessage 业务异常: responseData; } }这段脚本的含义很直接先判断HTTP状态码如果不是200就直接标记失败如果是200再判断响应体里是否包含error且同时包含500这种情况下业务上是异常的同样标记失败。注意Beanshell断言里的Failure是特殊对象必须大写F开头赋值true表示断言失败。FailureMessage是失败时输出的提示信息。别问我怎么知道的踩过坑的人都懂。3.4 上传文件场景的脚本处理搜索热词里还有“jmeter上传文件”这个在接口测试和压测里也不算少见。JMeter处理上传文件的核心在HTTP请求面板底部的“Files Upload”区域。操作方法在HTTP请求里把方法改成POST勾选“Use multipart/form-data”然后在Files Upload表格里填写“文件名称”为本地文件的绝对路径“参数名称”为后端接口接收文件的字段名“MIME类型”根据文件类型填写图片通常是image/png或image/jpeg文档是application/pdf。上传文件时要注意一点有些接口的上传请求除了文件字段还有业务字段比如文件描述、上传人ID。这些业务字段可以放到“参数”表格里JMeter会在multipart请求里同时携带参数和文件。如果文件较大比如几十MB上传请求会比较慢压测时需要关注超时设置。在HTTP请求的“超时”区域连接超时一般设3秒响应超时根据文件大小和网络情况来定可以设30秒或更长否则压测中途会报连接超时错误影响结果判断。4. 高并发压测与报告分析4.1 压测场景规划迁移验证的准备工作我前面提到那个迁移项目整套微服务从一个节点迁到云上ECS之后压测的目的非常明确验证云上环境的承载能力是否可以支撑原业务量的两到三倍同时确认迁移过程没有引入性能回退。做这个验证之前我习惯先把压测场景想清楚而不是直接打开JMeter随便填个100并发。接下来就是实操时应该认真准备的步骤第一确认压测脚本要覆盖哪些业务链路。如果是核心查询链路一个简单的GET请求就行如果是从登录到下单的完整购买流程就需要把登录、鉴权、业务接口串联起来中间加上参数抽取和关联。第二明确并发量和持续时间。热搜词里提到“模拟100用户并发报告”100并发是很多团队的起步值。但100并发到底意味着多少QPS得结合接口平均响应时间估算如果单接口平均响应时间是200毫秒100并发理论上可以支撑500 QPS。如果上线后预估峰值是1000 QPS那100并行线程远远不够需要调整线程组配置增加线程数或循环次数。第三准备监控手段。压测工具看到的TPS和响应时间是结果更关键的是要找到瓶颈出在哪。服务器上的CPU、内存、磁盘IO、网络带宽数据库的连接池占用情况都提前规划好怎么收集。最好是压测开始的同时在服务器上跑一个资源监控脚本或者直接用云监控平台这样出问题时能第一时间定位是应用层还是资源层的问题。提示云上的ECS实例规格、带宽、安全组规则都要提前和运维确认。尤其是安全组如果忘了放行压测机的IP和端口压测结果会千奇百怪可能大量超时错误但服务器端负载很低这种情况下先别急着调优系统先检查网络连通性。4.2 从聚合报告读懂性能指标压测跑完之后添加聚合报告监听器里面会有一堆统计指标。很多人对着这些数字一脸懵其实抓住核心的几项就够了。聚合报告里的核心指标Samples请求总数这个值等于线程数乘以循环次数。Average平均响应时间单位毫秒。Median中位数响应时间代表一半请求在这个时间内完成。90% Line90%的请求在这个时间内完成比平均响应时间更能反映真实感知。Min、Max最小和最大响应时间如果Max远大于90% Line说明有长尾请求存在可能有慢SQL或GC停顿。Error%错误率一般要求小于0.1%超过1%就要立即排查。Throughput吞吐量单位是请求/秒这个就是系统的实际QPS。我自己的分析习惯是先看错误率错误率高就先解决错误率错误率正常再看吞吐量和响应时间。响应时间看中位数和90% Line不盯着Average看因为平均值容易被极端值拉高。如果90% Line能保持在500毫秒以内大部分用户的体验就是流畅的。4.3 HTTPS录制与安全证书导入JMeter要录制HTTPS脚本时经常出现录制不到请求、或者浏览器提示证书问题。这背后的机制是JMeter的录制代理在本地扮演了一个中间人的角色浏览器发出的HTTPS请求会被JMeter用自签名证书解密这样JMeter才能看到请求内容。浏览器信任的证书列表里没有JMeter的这张自签名证书所以就会报警告提示。解决方案是把JMeter的信任证书导入到浏览器或系统信任列表里。JMeter从5.0版本开始在首次启动启动代理录制时会在bin目录下生成一个名为ApacheJMeterTemporaryRootCA.crt的证书文件。录制之前先把这个证书导入到浏览器或系统的“受信任的根证书颁发机构”里这样浏览器就不会再拦截JMeter的信誉级别。录制步骤大概是这样的先在JMeter里添加“HTTP(S)测试脚本记录器”配置端口号比如8888再到系统的代理设置里把HTTP和HTTPS代理都指向127.0.0.1:8888然后启动记录器在浏览器里正常访问目标站点JMeter就会自动把请求捕获到测试计划里。注意录制完成之后一定要把系统代理关掉否则浏览器访问其他网站也会走JMeter代理可能导致正常上网受影响。这个坑我踩过不止一次经常是录完忘关代理结果网页全部打开失败。4.4 高并发下的连接复用与Keep-Alive设置高并发压测时如果每个请求都新建TCP连接压测机和服务器都可能因为大量TIME_WAIT状态连接而耗尽资源。所以HTTP请求头里一般要设置Connection: keep-alive让JMeter复用已经建立的连接。JMeter的HTTP请求默认是使用Keep-Alive的但前提是你在线程组里添加了HTTP请求默认值并且在请求头里没有显式写Connection: close。如果压测中看到服务器端有大量TIME_WAIT状态的连接先检查压测请求是否合理地使用了长连接。同样服务器端也需要配置合理的Keep-Alive超时时间。超时太短连接很快被关闭频繁重建连接会增加开销超时太长空闲连接占用服务器资源。一般建议设置在5~15秒之间具体根据业务请求间隔来定。5. 常见报错与排查经验5.1 经典报错速查表压测和调试过程中总会遇到各种报错。以下是我在项目中实际遇到过、同时也在网上被高频搜索的报错问题整理报错信息常见原因处理方式java.io.IOException: Error writing to server网络中断、服务器主动断开连接、请求体过大检查网络增大请求超时时间确认服务器没有主动断开长连接__RequestVerificationToken 未提供必要的防伪标记MVC防伪令牌校验未通过通过正则提取器提取令牌并传递或通过Cookie管理器维护会话文件已经存在保存导出文件时目标文件被占用或已存在另存为其他文件名或删除旧文件后再保存Cannot load JDBC driver classJDBC驱动jar包缺失把对应数据库版本的驱动jar包放到JMeter的lib目录下并重启Connection refused服务器端口未开放、防火墙拦截、服务未启动使用telnet命令验证端口连通性检查安全组和防火墙规则Address already in use压测机本地端口耗尽减少压测机并发线程数启用端口复用用多台压测机做分布式压测这里面“java.io.IOException: Error writing to server”是最常见的尤其是压测一段时间后突然大量出现。我遇到过的实际情况是服务器端的连接空闲超时设置得太短导致长连接在一定时间后失效JMeter还在复用这个关闭的连接于是写数据时抛IOException。处理方式是在HTTP请求里把“KeepAlive”超时设置合理一些同时在JMeter的HTTP请求默认配置里调整超时时间。5.2 域名解析与Https证书特殊处理有时候HTTP请求配置没问题但压测时频繁报SSL证书验证失败或者响应时间异常高。这种情况多半是JMeter默认的SSL上下文没有信任目标服务器的自签名证书。解决方案有两个方向第一在JMeter的bin目录下执行openssl命令把服务器证书导入到JMeter使用的cacerts信任库里第二更常用的做法是在JMeter的system.properties文件里添加如下内容关闭SSL证书验证jmeter.ssl.use_system_propertiestrue不过关闭证书验证只是权宜之计它会让JMeter不再校验服务器证书但同时也意味着压测过程中不会真正模拟浏览器对证书的完整握手过程对于证书链检查严格的系统这种配置可能导致压测结果与真实用户访问不完全一致。对内部环境压测来讲关闭证书验证是可接受的。对正式的线上HTTPS压测建议还是把服务器证书正确导入信任库保证TLS握手过程真实可靠。5.3 分布式压测当一台压测机不够用单台压测机能发起的并发数受限于端口数、文件句柄数、CPU、内存、网络带宽。按照一个TCP连接占用一个本地端口计算单机TCP连接数上限约65535但真正达到几万并发时压测机本身的CPU和内存消耗已经很大压测结果就不再准确了。当单机压不动时就要考虑分布式压测。JMeter的分布式压测架构是一台Master调度机多台Slave执行机。Master把脚本分发到各台SlaveSlave各自发起请求最后把结果汇总回Master。配置方法不复杂每台Slave上安装JMeter启动bin目录下的jmeter-server.bat或jmeter-server.shMaster机器上修改bin目录下的jmeter.properties找到remote_hosts配置项填上各台Slave的IP和端口默认1099然后在Master的GUI里点击“运行”菜单下的“远程启动全部”就能把压测分发出去。这里有个关键点容易被忽视Master和所有Slave的JMeter版本必须一致否则会出现脚本无法加载或结果解析异常的问题。另外脚本中用到的CSV文件每台Slave上都要有否则Slave上会报文件不存在导致部分线程没有数据可用。5.4 MySQL密码配置与数据库连接池参数调整用JMeter做JDBC参数化的时候一个高频问题是MySQL密码配置错误。JMeter连接MySQL的密码在JDBC Connection Configuration的“密码”输入框里维护但这里有个容易踩的坑如果密码中包含特殊字符比如、#、$在JDBC URL里要正确编码或者把密码放到单独的配置元素里通过变量引用。JDBC Request自身的参数化取值逻辑也可能让人困惑。有些同学在JDBC Request里写了查询多行的SQL语句结果发现后续接口取不到数据这是因为JDBC Request默认只把查询结果的第一行存入变量多行数据需要通过遍历或指定变量名的_1、_2等后缀来引用。数据库连接池大小在高并发下也很敏感。如果JMeter需要同时发起大量数据库查询而连接池里只有10个连接剩下的请求会排队等待表现出来就是接口响应时间越来越长。建议压测前先评估数据库的并发能力调整JMeter的JDBC Connection Configuration里“最大连接数”配置让它和目标系统的数据库连接池大小匹配避免JMeter侧先成为瓶颈。高并发下数据库本身的连接数也可能成为瓶颈。压测过程中观察到接口响应时间从500毫秒突然涨到3秒以上服务器CPU不高、内存充足那大概率就是数据库连接池满了大量线程在等待获取连接。这时候要从数据库端确认连接池最大连接数设置同时考虑是否需要加缓存来降低数据库压力。6. 实际操作中的心得总结文章讲到这里JMeter从安装到脚本编写、参数化、断言、压力测试、报告分析、常见报错排查的完整链路基本上覆盖到了。最后再分享几个我在实际项目中沉淀下来的经验和习惯希望对你有参考价值。第一压测脚本一定要先小规模验证正确性再上大规模并发。我见过太多人一上来就设置1000并发跑了半小时发现错误率99%仔细一查是参数化文件路径错了、或断言写错了。先跑1个线程、循环1次打开察看结果树看看响应是否符合预期确认无误后再加并发。这是压测最基本的操作纪律也是保护自己不被无效数据坑惨的最好办法。第二压测结果要从多个角度交叉对比。不要只盯着聚合报告里的TPS要把聚合报告、响应时间趋势、服务器资源监控放在一起看。如果TPS上不去但服务器CPU已经100%说明瓶颈在服务端计算能力如果TPS上不去但服务器资源利用率很低说明瓶颈可能在数据库连接池、锁竞争或网络带宽。第三JMeter的脚本也要做版本管理。压测脚本虽然不像代码那么复杂但它会频繁调整不同的并发配置、参数文件、断言逻辑都会影响结果。我习惯把jmx脚本放到git仓库里每次改动留个commit记录这样谁改了脚本、改了哪些参数、对应的压测报告是哪一份全部可追溯。有了这个习惯复盘性能问题时能少走很多弯路。第四压测机本身的性能不能忽视。跑高并发压测时压测机资源不足会直接影响结果。我的做法是压测期间在压测机上执行top或打开任务管理器看CPU和内存占用。如果压测机CPU持续接近100%建议升级压测机或者用多台分布式压测分摊压力。JMeter说白了就是一个工具会点安装和录制只是入门真正有价值的是你对业务链路和系统架构的理解以及用数据说话的能力。做压测的经验是靠一次次踩坑攒出来的祝你在性能测试这条路上越走越顺。