那天下午我们刚把单节点 k8s 上的若依微服务整套环境迁到阿里云 ECS压测人员小 P 跑完配套的 JMeter 脚本屏幕上 TPS 三千、错误率 0%群里一片欢呼。可我盯着聚合报告看了一眼就乐了脚本里一个思考时间都没加每个线程循环 100 次打同一个登录接口响应数据还全是固定账号。这种压测跑一百遍也证明不了任何承载能力纯粹是给自己交差。别误会我不是否定 JMeter也不是否定压测这件事。我想说的是压测如果不模拟真实负载结果就只是个自欺欺人的数字。这篇文章把我这些年做性能测试踩过的坑、调过的脚本、以及这次 k8s 微服务迁移上云后的 JMeter 高并发压测验证过程完整梳理一遍。内容对刚接触压测的新手、以及正在做云上环境验收的老手都有参考价值重点解决一个问题怎么让压测结果真正反映线上承受能力。1. 为什么说没模拟真实负载压测就是在自欺欺人1.1 压测的本质不是测能扛多少并发而是测真实业务能不能跑很多团队对压测的理解停留在把并发数调大看系统崩不崩。这种理解不能说错但非常片面。压测的目标从来都不是得到一个并发 1000 不挂的指标而是回答一个更实际的问题真实用户按照正常业务习惯涌进来的时候系统还转不转得动响应还及不及时会不会丢请求、卡队列。打个比方。你在测一座桥能不能过货车最粗暴的做法是往桥上均匀地摆放同样重量的沙袋。沙袋放上去桥没塌你得出结论能承重。但真实情况是货车不是按同一速度均匀上桥的有的车满载、有的车超载有的车走走停停有的车还在桥中间突然刹车。桥的设计缺陷往往不是被均匀沙袋暴露的而是被这些不整齐的通行状态暴露的。压测也是一样真实负载最麻烦的地方就是不整齐。所以我在做验收类压测时第一条原则就是脚本里的请求不能长得一模一样。如果所有虚拟用户都在刷同一个静态页面、同一个固定参数的接口等于只在测 Web 容器和网络链路业务代码里真正吃资源的部分根本没碰测出来的 TPS 再高也和上线后的体验没关系。1.2 真实负载和简化压测负载到底差在哪我习惯用一张表给自己做脚本自检看当前写的脚本更接近真实负载还是安慰负载维度真实负载简化压测负载自欺欺人型请求链路多步骤串联登录→查询→操作→退出单接口或单页面反复打请求数据动态参数化上千组不同数据固定账号、固定ID、固定报文时间分布有思考时间有高峰低谷有波动匀速打无间隔或固定短间隔业务占比按真实场景混合比例分发只压最容易压的接口数据状态涉及新增、修改、删除数据在变只读数据越压越快这张表里的每一项背后都对应一个具体的失真原因。固定账号打接口Redis 缓存和数据库连接池几乎是打一次就热后续请求全在吃缓存红利匀速无思考时间等于把服务器的线程池和数据库连接池全部占满再测测的是并发上限但不是业务容忍度单接口反复压网关、鉴权、业务编排这些链路完全不经过发布后一上线就原形毕露。2. 用 JMeter 构造真实负载的关键细节2.1 线程组参数别乱拍并发数、Ramp-Up 和循环次数怎么配用过 JMeter 的人都知道线程组有三个基础参数线程数、Ramp-Up Period、循环次数。但真到配参数的时候很多人就是线程数 100Ramp-Up 填 1循环 100 次这么随手一填。这三个参数其实就是负载模型不能靠拍脑袋。先说 Ramp-Up。它的作用是设置启动所有线程需要多长时间。如果 100 个线程 Ramp-Up 填 1 秒意味着 1 秒内 100 个用户同时冲进来这模拟的是秒杀瞬间而不是常态。真实用户的到达是有先后、有间隔的所以我一般建议 Ramp-Up 至少设置成线程数的 1/2 到 1 倍也就是 100 个线程至少用 50 到 100 秒慢慢拉起来。这样能让系统有一个相对真实的负载爬坡过程看到 TPS 和响应时间随并发上升的曲线变化比一口气灌满有价值得多。再说循环次数。这里要引入一个压测基本公式TPS 线程数 / (平均响应时间 思考时间)。举个例子如果目标 TPS 是 500接口平均响应时间假设是 200 毫秒思考时间给 300 毫秒那么每个线程每秒能完成 2 个请求需要的线程数就是 500 / 2 250 个线程。确定线程数之后循环次数取决于你想让这个压力持续多久。一般压测至少要保持 10 到 15 分钟的稳定压力短于这个时间慢 SQL、内存泄漏、线程池堆积这类问题根本来不及暴露。提示循环次数比线程数更重要。线程数决定压力峰值循环次数决定压力持续时间。只关注前者测出来的往往是瞬时指标不是长期承载能力。2.2 Think Time 与定时器没有思考时间的脚本是假并发我在团队里经常说一句话没有思考时间的脚本测的不是业务系统是压力机网卡。真实用户不会连续不断地点按钮他看页面要花时间填表单要花时间犹豫要不要提交也要花时间。这个间隔在 JMeter 里就是 Think Time通常用定时器实现。JMeter 里最常用的是 Constant Timer 和 Gaussian Random Timer。Constant Timer 是固定延时适合模拟均匀操作Gaussian Random Timer 是高斯分布的随机延时更贴近真实用户有时候快有时候慢的行为。我个人默认用 Gaussian Random Timer参数上一般把 Deviation 设为 Delay 的 1/3 到 1/2。比如平均思考时间 2 秒Deviation 设 500 毫秒这样大部分用户的思考时间落在 1.5 到 2.5 秒之间偶尔有快的有慢的走势更真实。这里有个很多人忽略的点思考时间不能所有接口都加同一个值。用户在登录页停留的时间和下单后等待页面跳转的时间完全不是一个量级。正确做法是按业务步骤拆分登录后停留 1 到 2 秒查询结果看 3 到 5 秒提交后等待 2 到 3 秒。具体数值可以取自业务埋点没有埋点就让产品或者运营凭经验给总之不能一刀切。2.3 参数化和关联让请求千人千面固定参数是压测脚本里最隐蔽的失真源。用同一个账号登录 1 万次缓存里存的 token 永远是同一个用同一个订单号查 1 万次数据库索引命中的永远是同一条记录。这种压测跑出来的响应时间和你真实用户每人一个账号、每人查自己订单的响应时间完全是两回事。参数化在 JMeter 里用 CSV Data Set Config 最方便。先把测试数据准备成 CSV 文件比如账号、密码、业务单号各一列一次准备几千行脚本运行时每行数据被一个虚拟线程取走取完再循环。关联则解决另一个问题请求之间的依赖。若依微服务里典型的链路是登录接口返回 token后续所有业务接口带着这个 token 访问。如果脚本里所有用户用同一个登录态那等于没测网关鉴权的真实开销。正确的做法是用 JSON Extractor 或者正则表达式提取器从登录响应里把 token 动态抽出来再放到后续请求的 Header 里。这一步做不做压测结果能差出 30% 以上因为网关鉴权、token 校验、用户上下文加载都是真实的 CPU 和内存开销。2.4 性能测试指标别只盯 TPS压测报告里最显眼的永远是 TPS 和平均响应时间但这两个指标恰恰最容易骗人。TPS 高只能说明系统有吞吐能力如果错误率不为 0这个吞吐里有多少是有效请求就要打个问号。所以我每份报告里必看 5 个指标TPS、平均响应时间、TP95 响应时间、错误率、服务器资源占用率。TP95 比平均响应时间重要得多。平均响应时间 200 毫秒看起来很漂亮但如果有 5% 的请求要 3 秒对真实用户来说这 3 秒就是他感知到的卡顿。分布式系统里请求响应时间通常呈长尾分布只看平均就相当于我和姚明平均身高一米八。资源占用率则是压力侧的标尺。如果 CPU 没打满、内存没涨、线程池没满TPS 却上不去了说明瓶颈大概率在别处可能是数据库锁、网络带宽或者某个第三方依赖这时候继续加压力没有意义得先把瓶颈定位出来。3. 实战若依微服务迁移阿里云 ECS 后的 JMeter 压测验证3.1 迁移背景和这次压测的目标这次项目的背景是原本跑在单节点 k8s 上的整套若依微服务环境要迁到阿里云 ECS 上要求尽量不停服、不丢数据。迁移完成后的最后一步验收就是由压测人员用配套的 JMeter 脚本做高并发测试验证云上环境的承载能力。这里要说明一点迁移后的压测和从零搭建时的压测目标不一样。新系统压测是找上限迁移后压测是验证一致性。说白了我们要回答的问题只有一个迁移到云上之后核心业务在同等压力下响应和稳定性有没有劣化。所以脚本尽量复用迁移前跑过的场景保持并发模型和数据量一致跑出来的结果才有可比性。若依微服务涉及的组件不少Nacos 注册配置中心、Spring Cloud Gateway 网关、系统管理、认证授权、文件服务、定时任务等。压测时如果只压网关入口后面几条服务的链路都是通的还好说怕的是某个服务注册到 Nacos 的地址没变更、数据库连接池配置没调这些问题只有在真实业务链路压测时才会暴露。3.2 压测脚本搭建从登录到核心操作的完整业务链路这次我给小 P 定的脚本结构是这样的一条完整的业务链路从登录开始到获取用户信息、查询业务列表、提交一条业务数据、再退出登录结束。这几乎覆盖了若依后台管理系统里最高频的操作组合。线程组配置如下参数迁移前基线本次云上验证线程数200200Ramp-Up60 秒60 秒循环次数100100思考时间Gaussian 2 秒 ± 500msGaussian 2 秒 ± 500ms压测时长约 30 分钟约 30 分钟脚本关键步骤有五个第一步用 CSV 参数化准备 200 组账号数据每组账号对应独立的用户身份。第二步HTTP 请求里配置登录接口用 JSON Extractor 从响应里提取 token变量名设为 auth_token。第三步后续所有业务请求的 HTTP Header Manager 里引用 ${auth_token}这样每个虚拟用户都是独立登录态。第四步查询列表接口的查询条件用 CSV 里的参数传入不让所有用户查同一个关键词。第五步在关键节点加断言比如登录失败时返回的错误码以及提交业务数据后的成功标识这样跑完能直接统计业务成功率而不只是 HTTP 200 的数量。压测环境方面我把 JMeter 装在独立的压测机上不用执行机跑本机应用避免压力机自身资源成为瓶颈。压测机和云上 ECS 走内网减少网络延迟对响应时间的影响。这个细节看着小但对结果精度影响很大。3.3 执行与结果分析什么算云上承载能力达标脚本跑完之后我分析结果有一套固定动作不会只看聚合报告那个总览。第一步看错误率这次迁移后的首轮压测就暴露了一个问题错误率在跑到第 8 分钟时突然从 0 跳到 2.3%错误类型是连接超时。第二步看响应时间分布重点看 TP95确认是不是从某个并发点开始明显抬升。第三步看云上 ECS 的 CPU、内存、磁盘 IO 曲线和脚本压力曲线做时间轴对齐判断资源有没有被打满。这次首轮异常最终定位到网关服务的线程池配置迁移时 yaml 里的 server.tomcat.threads.max 沿用了原集群的小规格配置云上 ECS 规格更高但线程池没放大导致并发一上来线程池先耗尽请求排队超时。把线程池参数调大后重跑TPS 稳定在 2200 左右错误率归零TP95 从 1.8 秒回落到 900 毫秒以内。这里要强调的是迁移后的压测一定包含对比这个动作。我们把迁移前基线报告的 TPS、响应时间、错误率列成表逐项和云上结果做差值分析。只要核心指标不劣化超过 10%同时错误率为 0数据完整性校验通过这次迁移验收就算合格。只跑一遍、只看绝对数字看不出迁移有没有引入性能回退。4. 常见问题与排查技巧实录4.1 压测结果虚高的典型坑这些年我看过的压测报告里结果虚高的情况占了很大比例而且虚高的原因高度集中在四个地方问题表现为什么失真修正方案无思考时间TPS 异常高CPU 时间全在请求解析没有模拟用户阅读和操作间隔压力远超真实按业务步骤加 Gaussian Random Timer固定参数相同 token 反复命中缓存TPS 越压越高只测了缓存热路径没覆盖真实数据分布CSV 参数化至少准备千级独立数据单接口压测网关和编排链路未被触发微服务瓶颈根本不在入口接口按业务链路串多步骤请求压测数据量太小数据库索引全部进内存响应极快真实数据量大时会出现页缺失和慢查询测试库数据量按生产规模的 70% 以上准备这四类问题有一个共同特征压测结果相当漂亮但上线后系统表现完全对不上。如果你发现压测报告里 TPS 高得离谱、响应时间低得离谱先别高兴回头检查脚本是不是正好踩了这四类坑。4.2 结果不可信时的排查思路当压测结果和预期不符或者出现异常波动时我的排查顺序基本固定先确认是应用层问题还是脚本问题再逐层往下定位。第一步抓压力机侧数据。看 JMeter 所在机器的 CPU、网络、内存如果压力机自己 CPU 跑满结果里会出现大量假超时这是最容易误判的情况。第二步看网关和微服务的访问日志把压测时间段的请求数和响应码拉出来确认请求真实到达了后端而不是在负载均衡或网络层被丢弃。第三步看数据库连接数和慢查询压测时数据库连接池耗尽是最常见瓶颈慢查询日志能告诉你 SQL 层有没有问题。第四步看注册中心和配置中心迁移后的环境尤其要确认 Nacos 上注册的服务 IP 是否都是新 ECS 的地址有没有残留旧地址导致流量路由异常。我自己踩过一次印象很深的坑当时压测结果里错误率忽高忽低查了半天应用日志一切正常最后发现是压测机的网卡流量被别的任务占满了请求发出去了但响应包排队导致 JMeter 判定超时。那之后我每次压测前都会先确认压测环境的干净程度跑一轮 10 并发的小流量脚本做基线校验环境没问题再跑正式压力。4.3 我总结的几个压测习惯最后分享几个我在长期压测中养成的习惯不一定写进文档但确实帮我少踩了很多坑。第一正式压测前先做预热。系统刚启动时缓存、连接池、JIT 编译都还没到稳定状态这时候直接灌压力数据波动很大。我一般先用 20% 的目标压力跑 3 分钟让系统热起来再切换到正式压力。第二压测过程中别只盯监控大屏要在关键节点手动点几次页面亲身体验一下响应速度。数字是抽象的用户感受到的卡顿才是真实的。第三每一次脚本改动都要留版本记录。我在团队里强制要求脚本文件名带日期和场景标识比如 login_flow_20250620_v3.jmx否则压测完复盘时根本说不清楚当时跑的是什么配置。第四压测报告里必须有结论可复现信息脚本版本、压测机配置、测试数据量、执行时间段全部写清楚。不然三个月后想对比数据谁都不记得当时怎么跑的。回到开头那个场景。那天我拦下小 P 的报告之后我们重新按真实负载模型改写了脚本加了思考时间、做了参数化、串起了完整业务链路然后重新压了一天。结果很有意思第一次跑出来的 TPS 是三千重跑之后真实业务 TPS 稳定在一千八到两千二之间响应时间也上浮了不少但这次的结果才是云上环境真实承载能力的体现。迁移验收最终顺利通过靠的不是那个漂亮的假数字而是能经得起真实流量考验的结论。做性能测试这几年我最大的体会就是压测报告可以骗人但线上流量不会。与其到时候被真实用户打脸不如在压测阶段就狠一点把所有失真因素一个个揪出来补齐。
JMeter压测如何模拟真实负载？微服务上云后的高并发验证实战
那天下午我们刚把单节点 k8s 上的若依微服务整套环境迁到阿里云 ECS压测人员小 P 跑完配套的 JMeter 脚本屏幕上 TPS 三千、错误率 0%群里一片欢呼。可我盯着聚合报告看了一眼就乐了脚本里一个思考时间都没加每个线程循环 100 次打同一个登录接口响应数据还全是固定账号。这种压测跑一百遍也证明不了任何承载能力纯粹是给自己交差。别误会我不是否定 JMeter也不是否定压测这件事。我想说的是压测如果不模拟真实负载结果就只是个自欺欺人的数字。这篇文章把我这些年做性能测试踩过的坑、调过的脚本、以及这次 k8s 微服务迁移上云后的 JMeter 高并发压测验证过程完整梳理一遍。内容对刚接触压测的新手、以及正在做云上环境验收的老手都有参考价值重点解决一个问题怎么让压测结果真正反映线上承受能力。1. 为什么说没模拟真实负载压测就是在自欺欺人1.1 压测的本质不是测能扛多少并发而是测真实业务能不能跑很多团队对压测的理解停留在把并发数调大看系统崩不崩。这种理解不能说错但非常片面。压测的目标从来都不是得到一个并发 1000 不挂的指标而是回答一个更实际的问题真实用户按照正常业务习惯涌进来的时候系统还转不转得动响应还及不及时会不会丢请求、卡队列。打个比方。你在测一座桥能不能过货车最粗暴的做法是往桥上均匀地摆放同样重量的沙袋。沙袋放上去桥没塌你得出结论能承重。但真实情况是货车不是按同一速度均匀上桥的有的车满载、有的车超载有的车走走停停有的车还在桥中间突然刹车。桥的设计缺陷往往不是被均匀沙袋暴露的而是被这些不整齐的通行状态暴露的。压测也是一样真实负载最麻烦的地方就是不整齐。所以我在做验收类压测时第一条原则就是脚本里的请求不能长得一模一样。如果所有虚拟用户都在刷同一个静态页面、同一个固定参数的接口等于只在测 Web 容器和网络链路业务代码里真正吃资源的部分根本没碰测出来的 TPS 再高也和上线后的体验没关系。1.2 真实负载和简化压测负载到底差在哪我习惯用一张表给自己做脚本自检看当前写的脚本更接近真实负载还是安慰负载维度真实负载简化压测负载自欺欺人型请求链路多步骤串联登录→查询→操作→退出单接口或单页面反复打请求数据动态参数化上千组不同数据固定账号、固定ID、固定报文时间分布有思考时间有高峰低谷有波动匀速打无间隔或固定短间隔业务占比按真实场景混合比例分发只压最容易压的接口数据状态涉及新增、修改、删除数据在变只读数据越压越快这张表里的每一项背后都对应一个具体的失真原因。固定账号打接口Redis 缓存和数据库连接池几乎是打一次就热后续请求全在吃缓存红利匀速无思考时间等于把服务器的线程池和数据库连接池全部占满再测测的是并发上限但不是业务容忍度单接口反复压网关、鉴权、业务编排这些链路完全不经过发布后一上线就原形毕露。2. 用 JMeter 构造真实负载的关键细节2.1 线程组参数别乱拍并发数、Ramp-Up 和循环次数怎么配用过 JMeter 的人都知道线程组有三个基础参数线程数、Ramp-Up Period、循环次数。但真到配参数的时候很多人就是线程数 100Ramp-Up 填 1循环 100 次这么随手一填。这三个参数其实就是负载模型不能靠拍脑袋。先说 Ramp-Up。它的作用是设置启动所有线程需要多长时间。如果 100 个线程 Ramp-Up 填 1 秒意味着 1 秒内 100 个用户同时冲进来这模拟的是秒杀瞬间而不是常态。真实用户的到达是有先后、有间隔的所以我一般建议 Ramp-Up 至少设置成线程数的 1/2 到 1 倍也就是 100 个线程至少用 50 到 100 秒慢慢拉起来。这样能让系统有一个相对真实的负载爬坡过程看到 TPS 和响应时间随并发上升的曲线变化比一口气灌满有价值得多。再说循环次数。这里要引入一个压测基本公式TPS 线程数 / (平均响应时间 思考时间)。举个例子如果目标 TPS 是 500接口平均响应时间假设是 200 毫秒思考时间给 300 毫秒那么每个线程每秒能完成 2 个请求需要的线程数就是 500 / 2 250 个线程。确定线程数之后循环次数取决于你想让这个压力持续多久。一般压测至少要保持 10 到 15 分钟的稳定压力短于这个时间慢 SQL、内存泄漏、线程池堆积这类问题根本来不及暴露。提示循环次数比线程数更重要。线程数决定压力峰值循环次数决定压力持续时间。只关注前者测出来的往往是瞬时指标不是长期承载能力。2.2 Think Time 与定时器没有思考时间的脚本是假并发我在团队里经常说一句话没有思考时间的脚本测的不是业务系统是压力机网卡。真实用户不会连续不断地点按钮他看页面要花时间填表单要花时间犹豫要不要提交也要花时间。这个间隔在 JMeter 里就是 Think Time通常用定时器实现。JMeter 里最常用的是 Constant Timer 和 Gaussian Random Timer。Constant Timer 是固定延时适合模拟均匀操作Gaussian Random Timer 是高斯分布的随机延时更贴近真实用户有时候快有时候慢的行为。我个人默认用 Gaussian Random Timer参数上一般把 Deviation 设为 Delay 的 1/3 到 1/2。比如平均思考时间 2 秒Deviation 设 500 毫秒这样大部分用户的思考时间落在 1.5 到 2.5 秒之间偶尔有快的有慢的走势更真实。这里有个很多人忽略的点思考时间不能所有接口都加同一个值。用户在登录页停留的时间和下单后等待页面跳转的时间完全不是一个量级。正确做法是按业务步骤拆分登录后停留 1 到 2 秒查询结果看 3 到 5 秒提交后等待 2 到 3 秒。具体数值可以取自业务埋点没有埋点就让产品或者运营凭经验给总之不能一刀切。2.3 参数化和关联让请求千人千面固定参数是压测脚本里最隐蔽的失真源。用同一个账号登录 1 万次缓存里存的 token 永远是同一个用同一个订单号查 1 万次数据库索引命中的永远是同一条记录。这种压测跑出来的响应时间和你真实用户每人一个账号、每人查自己订单的响应时间完全是两回事。参数化在 JMeter 里用 CSV Data Set Config 最方便。先把测试数据准备成 CSV 文件比如账号、密码、业务单号各一列一次准备几千行脚本运行时每行数据被一个虚拟线程取走取完再循环。关联则解决另一个问题请求之间的依赖。若依微服务里典型的链路是登录接口返回 token后续所有业务接口带着这个 token 访问。如果脚本里所有用户用同一个登录态那等于没测网关鉴权的真实开销。正确的做法是用 JSON Extractor 或者正则表达式提取器从登录响应里把 token 动态抽出来再放到后续请求的 Header 里。这一步做不做压测结果能差出 30% 以上因为网关鉴权、token 校验、用户上下文加载都是真实的 CPU 和内存开销。2.4 性能测试指标别只盯 TPS压测报告里最显眼的永远是 TPS 和平均响应时间但这两个指标恰恰最容易骗人。TPS 高只能说明系统有吞吐能力如果错误率不为 0这个吞吐里有多少是有效请求就要打个问号。所以我每份报告里必看 5 个指标TPS、平均响应时间、TP95 响应时间、错误率、服务器资源占用率。TP95 比平均响应时间重要得多。平均响应时间 200 毫秒看起来很漂亮但如果有 5% 的请求要 3 秒对真实用户来说这 3 秒就是他感知到的卡顿。分布式系统里请求响应时间通常呈长尾分布只看平均就相当于我和姚明平均身高一米八。资源占用率则是压力侧的标尺。如果 CPU 没打满、内存没涨、线程池没满TPS 却上不去了说明瓶颈大概率在别处可能是数据库锁、网络带宽或者某个第三方依赖这时候继续加压力没有意义得先把瓶颈定位出来。3. 实战若依微服务迁移阿里云 ECS 后的 JMeter 压测验证3.1 迁移背景和这次压测的目标这次项目的背景是原本跑在单节点 k8s 上的整套若依微服务环境要迁到阿里云 ECS 上要求尽量不停服、不丢数据。迁移完成后的最后一步验收就是由压测人员用配套的 JMeter 脚本做高并发测试验证云上环境的承载能力。这里要说明一点迁移后的压测和从零搭建时的压测目标不一样。新系统压测是找上限迁移后压测是验证一致性。说白了我们要回答的问题只有一个迁移到云上之后核心业务在同等压力下响应和稳定性有没有劣化。所以脚本尽量复用迁移前跑过的场景保持并发模型和数据量一致跑出来的结果才有可比性。若依微服务涉及的组件不少Nacos 注册配置中心、Spring Cloud Gateway 网关、系统管理、认证授权、文件服务、定时任务等。压测时如果只压网关入口后面几条服务的链路都是通的还好说怕的是某个服务注册到 Nacos 的地址没变更、数据库连接池配置没调这些问题只有在真实业务链路压测时才会暴露。3.2 压测脚本搭建从登录到核心操作的完整业务链路这次我给小 P 定的脚本结构是这样的一条完整的业务链路从登录开始到获取用户信息、查询业务列表、提交一条业务数据、再退出登录结束。这几乎覆盖了若依后台管理系统里最高频的操作组合。线程组配置如下参数迁移前基线本次云上验证线程数200200Ramp-Up60 秒60 秒循环次数100100思考时间Gaussian 2 秒 ± 500msGaussian 2 秒 ± 500ms压测时长约 30 分钟约 30 分钟脚本关键步骤有五个第一步用 CSV 参数化准备 200 组账号数据每组账号对应独立的用户身份。第二步HTTP 请求里配置登录接口用 JSON Extractor 从响应里提取 token变量名设为 auth_token。第三步后续所有业务请求的 HTTP Header Manager 里引用 ${auth_token}这样每个虚拟用户都是独立登录态。第四步查询列表接口的查询条件用 CSV 里的参数传入不让所有用户查同一个关键词。第五步在关键节点加断言比如登录失败时返回的错误码以及提交业务数据后的成功标识这样跑完能直接统计业务成功率而不只是 HTTP 200 的数量。压测环境方面我把 JMeter 装在独立的压测机上不用执行机跑本机应用避免压力机自身资源成为瓶颈。压测机和云上 ECS 走内网减少网络延迟对响应时间的影响。这个细节看着小但对结果精度影响很大。3.3 执行与结果分析什么算云上承载能力达标脚本跑完之后我分析结果有一套固定动作不会只看聚合报告那个总览。第一步看错误率这次迁移后的首轮压测就暴露了一个问题错误率在跑到第 8 分钟时突然从 0 跳到 2.3%错误类型是连接超时。第二步看响应时间分布重点看 TP95确认是不是从某个并发点开始明显抬升。第三步看云上 ECS 的 CPU、内存、磁盘 IO 曲线和脚本压力曲线做时间轴对齐判断资源有没有被打满。这次首轮异常最终定位到网关服务的线程池配置迁移时 yaml 里的 server.tomcat.threads.max 沿用了原集群的小规格配置云上 ECS 规格更高但线程池没放大导致并发一上来线程池先耗尽请求排队超时。把线程池参数调大后重跑TPS 稳定在 2200 左右错误率归零TP95 从 1.8 秒回落到 900 毫秒以内。这里要强调的是迁移后的压测一定包含对比这个动作。我们把迁移前基线报告的 TPS、响应时间、错误率列成表逐项和云上结果做差值分析。只要核心指标不劣化超过 10%同时错误率为 0数据完整性校验通过这次迁移验收就算合格。只跑一遍、只看绝对数字看不出迁移有没有引入性能回退。4. 常见问题与排查技巧实录4.1 压测结果虚高的典型坑这些年我看过的压测报告里结果虚高的情况占了很大比例而且虚高的原因高度集中在四个地方问题表现为什么失真修正方案无思考时间TPS 异常高CPU 时间全在请求解析没有模拟用户阅读和操作间隔压力远超真实按业务步骤加 Gaussian Random Timer固定参数相同 token 反复命中缓存TPS 越压越高只测了缓存热路径没覆盖真实数据分布CSV 参数化至少准备千级独立数据单接口压测网关和编排链路未被触发微服务瓶颈根本不在入口接口按业务链路串多步骤请求压测数据量太小数据库索引全部进内存响应极快真实数据量大时会出现页缺失和慢查询测试库数据量按生产规模的 70% 以上准备这四类问题有一个共同特征压测结果相当漂亮但上线后系统表现完全对不上。如果你发现压测报告里 TPS 高得离谱、响应时间低得离谱先别高兴回头检查脚本是不是正好踩了这四类坑。4.2 结果不可信时的排查思路当压测结果和预期不符或者出现异常波动时我的排查顺序基本固定先确认是应用层问题还是脚本问题再逐层往下定位。第一步抓压力机侧数据。看 JMeter 所在机器的 CPU、网络、内存如果压力机自己 CPU 跑满结果里会出现大量假超时这是最容易误判的情况。第二步看网关和微服务的访问日志把压测时间段的请求数和响应码拉出来确认请求真实到达了后端而不是在负载均衡或网络层被丢弃。第三步看数据库连接数和慢查询压测时数据库连接池耗尽是最常见瓶颈慢查询日志能告诉你 SQL 层有没有问题。第四步看注册中心和配置中心迁移后的环境尤其要确认 Nacos 上注册的服务 IP 是否都是新 ECS 的地址有没有残留旧地址导致流量路由异常。我自己踩过一次印象很深的坑当时压测结果里错误率忽高忽低查了半天应用日志一切正常最后发现是压测机的网卡流量被别的任务占满了请求发出去了但响应包排队导致 JMeter 判定超时。那之后我每次压测前都会先确认压测环境的干净程度跑一轮 10 并发的小流量脚本做基线校验环境没问题再跑正式压力。4.3 我总结的几个压测习惯最后分享几个我在长期压测中养成的习惯不一定写进文档但确实帮我少踩了很多坑。第一正式压测前先做预热。系统刚启动时缓存、连接池、JIT 编译都还没到稳定状态这时候直接灌压力数据波动很大。我一般先用 20% 的目标压力跑 3 分钟让系统热起来再切换到正式压力。第二压测过程中别只盯监控大屏要在关键节点手动点几次页面亲身体验一下响应速度。数字是抽象的用户感受到的卡顿才是真实的。第三每一次脚本改动都要留版本记录。我在团队里强制要求脚本文件名带日期和场景标识比如 login_flow_20250620_v3.jmx否则压测完复盘时根本说不清楚当时跑的是什么配置。第四压测报告里必须有结论可复现信息脚本版本、压测机配置、测试数据量、执行时间段全部写清楚。不然三个月后想对比数据谁都不记得当时怎么跑的。回到开头那个场景。那天我拦下小 P 的报告之后我们重新按真实负载模型改写了脚本加了思考时间、做了参数化、串起了完整业务链路然后重新压了一天。结果很有意思第一次跑出来的 TPS 是三千重跑之后真实业务 TPS 稳定在一千八到两千二之间响应时间也上浮了不少但这次的结果才是云上环境真实承载能力的体现。迁移验收最终顺利通过靠的不是那个漂亮的假数字而是能经得起真实流量考验的结论。做性能测试这几年我最大的体会就是压测报告可以骗人但线上流量不会。与其到时候被真实用户打脸不如在压测阶段就狠一点把所有失真因素一个个揪出来补齐。
