压测这件事，说简单也简单，ab 或者 wrk 敲一行命令就能跑；说复杂也复杂，要模拟真实业务链路、要分布式发压、要实时看 TPS 和 RT 的拐点。这些年我用过不少压测工具，今天重点聊聊 JMeter、LoadRunner 和阿里云 PTS 这三个，分享一些实际踩坑经验。
JMeter：开源首选，但别小看调优
JMeter 是我用得最多的。安装简单，wget 下载解压，jmeter -n -t test.jmx -l result.jtl 就能跑。但第一次用它压 5000 并发时，我遇到了经典问题：发压机自己先扛不住了。
默认 JVM 堆只有 1GB，我改 jmeter 脚本里的 HEAP 参数：
HEAP="-Xms4g -Xmx4g -XX:MaxMetaspaceSize=512m"
同时在 user.properties 里调整：
jmeter.save.saveservice.output_format=csvjmeter.save.saveservice.response_data=falsejmeter.save.saveservice.samplerData=false
关掉响应数据保存，否则 JTL 文件能涨到几十 GB，IO 直接打满。
还有一个坑：JMeter 的 GUI 模式只适合调试，正式压测必须用 CLI。我见过同事开着图形界面压 2000 并发，结果自己电脑卡死，还以为是服务端问题。
分布式压测时，jmeter-server 的 server.rmi.ssl.disable=true 要配好，否则控制机和执行机之间通信会出问题。不过 JMeter 的分布式方案在大规模场景下管理起来比较麻烦，需要自己维护多台发压机。
LoadRunner：功能强大，但成本不低
LoadRunner 是老牌商业工具，协议支持非常全，分析报表也很专业。我上一家公司采购过，一个 1000 并发的 license 价格不菲。
它的 VuGen 录制脚本确实方便，但脚本语言是 C，调试起来门槛不低。有一次我写了个参数化脚本：
lr_save_string(lr_eval_string("{username}_{iteration}"), "dynamic_user");web_submit_data("login","Action=https://api.example.com/login","Method=POST","RecContentType=application/json","Body={\"user\":\"{dynamic_user}\",\"pass\":\"{password}\"}", LAST);
跑起来发现事务响应时间比 JMeter 高不少，后来才明白是 LoadRunner 的默认超时和思考时间设置更保守，需要手动调 web_set_timeout 和 lr_think_time。
LoadRunner 的优势在于企业级支持，遇到问题可以找官方。但对我们这种中小团队来说，采购成本和维护成本都偏高，而且它需要 Windows 环境，和我们的 CI/CD 流水线集成不太顺畅。
阿里云 PTS：云原生时代的省心选择
去年大促前，我们决定试试阿里云 PTS。原因很简单：不想再维护发压机了。
PTS 的控制台设置很直观，支持 JMeter 脚本直接上传，也支持原生场景编排。我上传了一个 .jmx 文件，设置好并发梯度：
并发数：500 → 1000 → 2000 → 5000每阶段持续时间：5分钟
PTS 自动分配发压资源，实时展示 TPS、RT、成功率曲线。最让我满意的是它的压测报告，能直接定位到哪个接口是瓶颈，还能对比不同压测批次的数据。
价格方面，按量付费，我们那次压了 2 小时，费用不到 200 块。相比自己买几台 8 核 16G 的 ECS 做发压机，省心太多。
不过 PTS 也有局限：它毕竟是云服务，对私有化搭建的场景支持有限。另外，压测流量从公网进来，如果服务端有 IP 白名单策略，需要提前设置好放行规则。
选型建议：看场景，别看广告
总结一下我的经验：
- 小规模调试、开源可控：选 JMeter，但记得调 JVM 和关闭冗余日志。
- 企业级协议覆盖、预算充足：LoadRunner 仍然能打，但要做好长期投入准备。
- 快速上手、弹性发压、不想运维发压机：PTS 是最优解，尤其适合大促前的短时高并发验证。
最后说个踩坑心得：不管用哪个工具，压测前一定要和业务方对齐目标。是验证峰值 TPS，还是找系统拐点？是压单接口，还是全链路？目标不同，工具设置和压测策略完全不一样。
那次晚高峰问题，最后用 PTS 压出了瓶颈——是数据库连接池太小。调整 max_connections 后，系统稳稳扛住了大促。压测工具只是手段，找到瓶颈、解决问题才是目的。
希望这篇对比能帮你在下次压测时少走弯路。
👨💻 运维老兵经验：根据实际生产环境，以上步骤建议先在测试环境验证，并做好备份。参数值需根据服务器设置调整，不要盲目照搬。
