1. 从“高并发”到“持续高并发”这个测试方案到底想验证什么接到这个项目时目标其实很朴素——用JMeter把被测系统的性能底牌摸清楚。但标题里的“高并发”“高频率”“弱压力”“持续高并发”这几个词放在一起说明这绝不是简单地把线程数拉到500然后跑一遍看响应时间就完事。先说结论高并发测的是系统扛不扛得住峰值高频率测的是处理单元在单位时间内的吞吐上限弱压力测的是系统在低负载下的稳定性和资源消耗基线持续高并发测的是长时间运行下有没有内存泄漏、连接池耗尽、GC频繁这类慢性病。四者目标完全不同脚本设计和参数设置也完全不同。这个方案适合谁参考如果你是刚接手性能测试、被领导要求“压一下看看并发能到多少”的新手或者是在做上线前的容量评估、故障复盘时需要重现问题的开发这套思路可以直接抄作业。我在这篇文章里会把四个场景的参数设计逻辑、JMeter里的具体配置、以及我实际跑压测时踩过的坑全部写出来。注意本文所有案例基于JMeter 5.x版本JDK使用8u202及以上。JMeter本身是Java应用JDK版本不对的话高并发下经常会出现莫名其妙的卡顿或线程启动失败这一点后面会详细说。2. 环境准备与基础配置JMeter装不对后面全是坑2.1 JDK8与JMeter的版本匹配问题热词里出现了“jmeter 安装 jdk 8”和“jmeter下载安装教程”说明很多人在环境这步就被卡住了。JMeter 5.4.1及以上版本官方要求Java 8但注意不要盲目上JDK 17这类新版本——JMeter的某些插件尤其是Beanshell相关的在JDK 9以后的模块化体系下会出现类访问权限问题。我的建议组合JMeter 5.4.1 JDK 8u202 或 8u333。JDK的安装不赘述但装完后必须配JAVA_HOME环境变量否则JMeter的启动脚本会找不到Java。验证是否装好命令行执行java -version jmeter -v看到JMeter版本号就说明基础环境OK了。Mac用户可以直接命令行安装brew install jmeterLinux用户sudo apt install jmeterWindows用户去官网下载zip包解压后运行bin/jmeter.bat即可。2.2 高并发必须调整的内存参数默认JMeter启动堆内存只有1G跑高并发时聚合报告和结果树会占用大量内存很容易出现OutOfMemoryError。这个时候压测结果就废了——不是系统扛不住而是压测工具自己先崩了。找到bin/jmeter.bat或jmeter.sh里的这一行HEAP-Xms1g -Xmx1g -XX:MaxMetaspaceSize256m改成HEAP-Xms4g -Xmx4g -XX:MaxMetaspaceSize512m4G是一个相对稳妥的值。如果本机内存只有8G就给JMeter分配3G留出足够的操作系统内存。我在压测时习惯把聚合报告里的“仅日志错误”以外的功能全部关掉——结果树、断言结果这些监听器在高并发时必须禁用否则光是写日志就能把JMeter所在机器的CPU吃满。2.3 高并发前的基础检查清单在脚本正式开跑之前我建议花10分钟过一遍这个检查清单能省掉后面一大半的排查时间压测机的网络连接数是否受限Linux下执行ulimit -n小于65535就执行ulimit -n 65535Windows本机压测时关闭防火墙或者放行JMeter的端口被测系统的连接池设置、数据库最大连接数、线程池核心线程数都要提前拿到配置值压测机和被测机器的时间同步否则聚合报告里的时间戳和服务器日志对不上定位问题会非常痛苦3. 四类压力场景的参数设计线程数不是越大越好3.1 高并发测试线程数、Ramp-Up周期与循环次数的数学关系高并发场景的核心诉求是在短时间内制造大量并发请求模拟峰值流量。JMeter里控制并发的三个核心参数是线程数、Ramp-Up周期秒、循环次数。很多新手直接把线程数拉到1000Ramp-Up留默认的1秒结果一启动压测机直接卡死。这是因为JMeter的线程模型是“一用户一线程”1000个线程在1秒内全部启动线程切换开销会极大影响压测机的CPU被测系统收到的也不一定是真实业务流量而是连接风暴。我的做法是分两步计算第一步算Ramp-Up周期。经验公式是Ramp-Up 总线程数 / 每秒启动线程数。如果目标是模拟真实用户在1分钟内逐渐涌入那1000线程就设置Ramp-Up为60秒相当于每秒启动约17个线程。这个参数的意义是让负载呈渐进式增长观察系统在没有被瞬时击穿的情况下TPS和响应时间的变化曲线。第二步算循环次数。很多场景下循环次数不需要设太大——高并发测的是“一瞬间能扛住多少”不是“长时间能处理多少”。如果接口是查询类的建议循环次数设置成10次以内配合定时器控制请求频率。经验值单机JMeter建议线程数控制在2000以内。超过2000就上分布式压测否则压测机自身会成为瓶颈。这不是硬性限制而是我实测下来JMeter线程超过2000后线程调度和监听器数据采集的CPU开销会明显上涨影响测试准确性。3.2 高频率测试弱线程数配高循环次数高频率场景其实是另一种并发形态并发不高但每个用户在极短的时间内发出大量请求。典型的业务是消息推送、WebSocket心跳、轮询接口。这类场景下200个线程、循环次数500次配合一个常驻的“固定定时器”Constant Timer就能模拟出高频率请求的效果。固定定时器的单位是毫秒比如设置500ms意味着每个线程每次请求后等待500毫秒再发下一次请求。这里有一个容易被忽略的点固定定时器是作用在每个取样器上的不是每个线程上。如果线程组里有两个HTTP请求每个请求后都会等待500ms总间隔就是1秒。这不是你要的效果的话就在取样器层面单独配置或使用“Flow Control Action”来精确控制。高频率测试的核心观测指标是TPS和网络带宽。我在实际压测中经常遇到这样一种情况TPS曲线平直但响应时间不断上升——这不是系统处理不过来而是网络带宽被打满了。这种问题要先去压测机的nload或iftop看一眼不要一上来就断定是应用层的问题。3.3 弱压力测试低频、低并发下的稳定性验证弱压力场景往往是被抛弃的那一个但它恰恰能发现高并发测不出来的问题。它的定义是在系统预设负载的30%-40%以下持续运行一段较长时间观察资源占用和错误率。配置上很简单20个线程、Ramp-Up 5秒、循环次数设置为永远最后在“调度器”里勾选“持续时间秒”填写1800秒30分钟。但这个场景最值得关注的是三类指标GC频率与耗时、数据库连接池的空闲连接回收情况、JVM堆内存的曲线变化。弱压力下如果出现内存持续增长而不回落的迹象那基本可以判定是内存泄漏。这类问题在高并发场景下会被性能瓶颈掩盖反而不容易暴露。3.4 持续高并发测试调度器与“永远”循环的正确用法持续高并发是上线前最重要的一个场景它要把前面所有场景的结果放在一起验证能否在较高并发下长时间稳定运行。参数设置上线程数取高并发峰值的70%-80%循环次数改为“永远”然后在调度器中勾选“持续时间秒”比如3600秒1小时。有些团队会跑12小时甚至24小时我的经验是1小时的持续高并发能暴露90%以上的稳定性问题24小时主要针对内存泄漏类慢性问题大部分项目跑1-2小时足矣。这里还要注意“启动时间秒”和“持续时间秒”的区别。启动时间是指所有线程启动完成需要的时间持续时间是开始运行后到自动停止的时间。如果两个都填了JMeter会在启动时间结束后再开始计算持续时间。注意使用“永远”循环和调度器时脚本运行结束后聚合报告里的样本数会非常大。建议在监听器配置里勾选“所有数据写入一个文件”保存为csv格式避免长时间运行时JMeter界面卡死。4. 脚本细节与断言设计高并发场景下的“隐形”杀手4.1 Beanshell断言的实际运用热词里出现了“jmeter beanshell断言”说明很多人被断言功能卡住了。高并发场景下响应断言Response Assertion虽然简单但遇到需要“对返回内容做逻辑判断”的场景就不够用了。比如一个登录接口成功返回JSON里code200且data.token不为空失败返回code500但不一定是接口异常——可能是账号被锁定。这种用“响应文本包含”匹配很难表达清楚必须用Beanshell脚本。在“登录请求”下面右键添加“Beanshell断言”import org.json.JSONObject; String response prev.getResponseDataAsString(); JSONObject json new JSONObject(response); if (json.getInt(code) ! 200) { Failure true; FailureMessage 登录失败错误码 json.getString(msg); } String token json.optString(data.token); if (token null || token.length() 0) { Failure true; FailureMessage 响应中未返回有效token; }这里有两个关键API需要记住prev.getResponseDataAsString()获取响应内容Failure和FailureMessage是Beanshell断言中控制判定结果的公共变量。高并发场景下不建议在BeanShell里做太复杂的逻辑运算如果必须做可以用JSR223断言配合Groovy——Groovy的执行效率比BeanShell高一个数量级在10万级样本下会明显影响TPS计数。4.2 文件上传与中文文件名乱码热词里“jmeter上传文件中文文件名乱码”是我见过被问得最多的问题之一。Jmeter在HTTP请求里做文件上传时默认的文件名编码和HTTP头里的编码不一致会导致乱码进而导致服务器端拒绝请求。解决方案有两个。第一个是修改JMeter的配置文件在bin/jmeter.properties里取消注释并修改sampledata.filename.encodingUTF-8第二是在HTTP请求取样器里找到“HTTP Client Implementation”使用Java实现并额外添加“HTTP信息头管理器”设置Content-Type为multipart/form-data; charsetUTF-8。# 在HTTP请求的“文件上传”选项卡 文件名: /path/to/测试报告.pdf 参数名: file MIME类型: application/pdf实测下来修改sampledata.filename.encodingUTF-8能解决90%的乱码问题。还有10%的情况是服务器端读取时用了ISO-8859-1那就是程序问题了压测工具改再多也没用需要开发配合修复。4.3 HTTPS脚本录制与安全证书处理热词里“jmeter录制https脚本”和“jmeter安全证书”也是很常见的卡点。录制HTTPS脚本本质上就是让JMeter作为中间人代理。在JMeter的bin目录下找到ApacheJMeterTemporaryRootCA.crt导入到浏览器的受信任根证书列表。Chrome和Firefox在代理设置上稍有不同但要记住一个关键录制时如果浏览器报了证书错误不要点“继续访问”跳过这会导致JMeter收到的不是完整SSL握手信息。实际上在我自己的压测项目中已经很少用录制这种方式了。主流做法是用浏览器开发者工具F12直接导出HTTP请求为HAR文件再用JMeter的“HAR文件导入”功能转成测试计划。这种方式比录制干净得多不容易带入无关请求。4.4 数据库压测脚本与MySQL高并发热词里“jmeter数据库压测脚本”和“mysql高并发解决方案”暗示了一个场景性能瓶颈往往在数据库层。JMeter连接MySQL需要先把mysql-connector-java的jar包放到lib/ext目录下然后在测试计划里添加“JDBC Connection Configuration”Database URL: jdbc:mysql://host:3306/dbname?useSSLfalseserverTimezoneAsia/Shanghai JDBC Driver Class: com.mysql.cj.jdbc.Driver Username: root Password: 123456这里的serverTimezone参数强烈建议加上——JDBC连接MySQL 8.x时时区不匹配会直接报错。数据库压测脚本的核心不是怎么写SQL而是区分查询类型。高并发查询需要连接池足够大高并发写入则需要关注事务隔离级别和锁竞争。在JDBC Request里如果SQL是查询查询类型选“Select Statement”如果是批量插入选“Prepared Update Statement”会显著提升执行效率。我做MySQL高并发压测时发现两个高频问题一是连接池的连接数默认只有10压测线程一多直接报Too many connections二是数据库配置文件里的innodb_buffer_pool_size往往设定太小。前者需要在连接串里加上maxPoolSize配置后者是数据库本身的调优问题需要DBA介入调整。5. 结果分析与瓶颈定位聚合报告里的数字藏着系统底牌5.1 聚合报告与关键指标解读JMeter的“聚合报告”Summary Report是最终的成绩单但90%的人只关注了“Average”和“Throughput”。真正有价值的指标是下面这几个90% Line / 95% Line / 99% Line这组百分位数能反映响应时间的长尾分布。平均值是500ms不代表系统健康——如果99% Line是5000ms说明少量请求卡了5秒这对用户体验是致命的。Error%错误率上升时先看是哪个取样器的错误再看错误类型。最烦人的不是HTTP 500而是SocketTimeout——这种错误往往被断言的“忽略异常”选项掩盖。Received KB/sec如果这个值很高但TPS很低说明响应包太大典型场景是接口返回了不需要的大字段列表如果这个值很低但TPS很高说明是纯计算型接口或内存型缓存磁盘I/O不是瓶颈。我的习惯是压测结束后把聚合报告导出成CSV然后用Excel做两个数据透视表一个按时间分组看TPS和响应时间趋势一个按接口分组看错误分布。只看汇总报告不看趋势等于考试只看了总分没看每道题的得分。5.2 高并发下的“阶梯加压”策略直接压满线程数是一种赌博式测试——你没做摸底的时候系统可能扛不住瞬时冲击不是系统Bug而是你的压测方式本身造成的雪崩。我推荐的做法是“阶梯加压”在同一测试计划中设置多个线程组或者用“Stepping Thread Group”插件。第一个线程组50线程跑60秒第二个线程组100线程跑60秒……逐步递增每跑完一级就记下当前的TPS和响应时间。这种方式的优势在于能精准找到系统的拐点——TPS不再随线程数增长甚至出现下降的那一级就是系统的并发极限。在这个拐点附近再做一次5分钟短压把资源使用率、线程状态、连接池等待时间一起抓出来分析。阶梯加压的另一个用途是验证“弱压力”场景下的系统表现如果50线程甚至20线程时响应时间就高得离谱那问题不在并发能力而在基础响应链路网络延迟、DNS解析、代码效率上。5.3 高并发场景下JMeter自身的监控性能测试里有个著名的“先测试测试工具”的原则。JMeter作为Java进程自身也可能成为瓶颈。高并发压测时我至少会开一个终端跑jstat监听JMeter的JVM状态jstat -gcutil jmeter_pid 1000如果Full GC次数频繁且耗时上百毫秒说明压测机资源不足或者你开的监听器太多了此时得到的被测系统性能数据是不准确的。通常在压测期间我会把所有不必要的监听器全部禁用只保留“简单数据写入器”和“聚合报告”压测结束后再把结果文件导入回来看详细数据。6. 高频问题排查把这九类问题记住能少加一周班6.1 JMeter启动与运行时的经典报错报错1“could not delete existing file C:\Windows\System32...”这个问题在热词里出现了我当年也被坑过。原因是JMeter在Windows下高并发运行时需要生成临时文件来缓存采样结果但杀毒软件或安全策略把System32目录下的文件锁定了。处理方法给JMeter设置独立临时目录在jmeter.properties里添加dont_delete_system_temptrue java.io.tmpdirD:/tmp/jmeter报错2Java内存溢出OutOfMemoryError前面说过调整HEAP参数。还有一个小技巧压测结束后不要立即打开“查看结果树”先把结果文件保存好否则大结果集直接加载会把内存打爆。报错3BeanShell断言执行异常高并发时BeanShell脚本如果出现未知异常默认会直接让线程失败。在断言里加一个try-catch兜底import org.json.JSONObject; try { String response prev.getResponseDataAsString(); JSONObject json new JSONObject(response); ... } catch (Exception e) { Failure true; FailureMessage 断言脚本异常 e.toString(); }6.2 性能数据异常时的排查顺序如果压测结果出现TPS极低、错误率极高的情况不要直接怀疑系统。按下面的顺序排查压测机自身的CPU/内存是否打满压测机本身瓶颈网络带宽是否打满iptraf或iftop查看连接数是否耗尽ss -s查看当前TCP连接状态被测系统CPU、内存、磁盘I/O、GC情况数据库慢查询日志和连接池状态以上五步按顺序走一遍90%的“性能异常”都能定位到根因。我见过太多人刚学会JMeter一看到响应时间缓慢就说“服务挂了”结果只是压测机网卡被占满。6.3 弱压力不弱低并发下的异常定位技巧弱压力场景下并发不高如果依然出现错误问题往往比较“深”。有次我用30线程压一个列表查询接口错误率在8%左右徘徊查了四个小时最后发现是被测系统的某个查询条件没有走索引全表扫描把CPU拖垮了。弱压力下的排查重点应该放在单次请求的完整链路追踪上——打开“查看结果树”找一两个错误的请求样本把响应数据和请求头对齐结合服务端日志的traceId查全链路。这种问题在高并发下反而不容易定位因为错误被淹没在海量请求里。7. 最后分享几个我长期积累的实测经验做了这些年压测我把几条“血泪教训”写在最后供参考一永远不要相信聚合报告第一次出来的平均值。压测前先发几个热身请求等聚合报告的数字稳定了再开始正式压测。JVM有冷热之分应用运行时第一次请求可能要加载很多类、初始化连接池数值会虚高。二脚本参数化一定要做。1000个线程全部请求同一个账号、同一个订单号服务器把数据放进了缓存你在压缓存不是压系统。用CSV或JMeter函数生成随机参数把用户数据、商品数据、订单数据全部参数化这样压出来的结果才接近真实业务。三压测计划要有版本管理。JMeter的jmx文件是XML结构的可以直接进Git。压测脚本也是一种资产今天测的和上周测的可能参数不同没有版本管理对比数据时根本说清楚差异。四持续时间不要只看“跑完没报错”。持续高并发测试跑完后还要看一眼服务器重启过没有、日志有没有大量WARN级别告警、数据库连接池有没有逐渐增长到连接数上限。有些问题在压测过程中没暴露但在压测结束后会滞后出现比如Redis连接泄漏——结束后半小时Redis连接数才慢慢降下来这种就是典型的连接管理Bug。性能测试这个活儿脚本只是工具真正有价值的是“把数据背后的系统行为读懂”。用JMeter做高并发、高频、弱压力、持续高并发这套组合拳本质上是逼着系统把自己最真实的一面亮出来。跑完一轮你对系统的了解往往比开发还深。希望这篇实战记录能帮你少踩一些我已经踩平了的坑。