jmeter如何做性能测试：分步落地实操

jmeter如何做性能测试，整套流程分为脚本录制调试、线程组配置、压测参数设置、监听器添加、分布式压测执行、结果分析六个环节，你优先在单台机器完成脚本验证，单机能支撑的并发上限多在200至500线程，超过这个量级就要启用分布式压测，该方案适合接口、http网页类服务，不适合长连接实时推送类应用，压测前必须确认目标服务有独立测试环境，禁止直接在生产环境发起压测请求。

jmeter如何做性能测试之脚本构建

新建测试计划后，先添加线程组，线程组是jmeter里用来模拟虚拟用户的容器，一个线程对应一个虚拟用户。你可以用HTTP请求取样器手动填写接口地址、请求方式、请求头和请求参数，也可以用HTTP代理服务器录制浏览器请求，录制前要在浏览器手动配置代理地址为127.0.0.1，端口和jmeter代理端口保持一致，录制完成后及时清理多余的静态资源请求，图片、css、js这类资源请求会拉高线程占用，干扰接口本身的性能指标。

加断言校验响应结果。

响应断言用来判断接口返回是否符合预期，一般选择响应代码200或者响应文本关键词，避免压测过程把报错请求统计成成功请求。接口存在登录态时，添加HTTP信息头管理器放入token，或者用JSON提取器从上一个接口返回结果里提取token传递给后续接口，提取器的引用名称、JSON路径表达式、匹配数字三个参数填写错误，会直接导致后续接口全部请求失败。

jmeter如何做性能测试之压测场景配置

线程组有三种常用类型，不同类型对应不同压测目标，对比信息如下。

普通线程组里ramp-up时间代表所有线程启动消耗的总秒数，设置过短会瞬间打满服务，无法还原真实用户流量模型，设置过长会拉长压测周期，常规取值按线程数除以10来估算。勾选调度器可以设置压测持续时长，稳定压测场景建议持续运行5到10分钟，短时间压测很难暴露内存缓慢上涨、连接池耗尽这类慢生效问题。

jmeter如何做性能测试之监听器与数据采集

监听器负责收集和展示压测数据，你不要在线上压测阶段开启查看结果树，这个组件会占用大量内存，高并发场景下容易让jmeter客户端先卡顿崩溃。压测执行阶段优先使用汇总报告、聚合报告，聚合报告可以直接输出平均响应时间、TPS、错误率、90%响应时间这些核心指标，指标判断参考：业务接口错误率需要维持在0.5%以内，90%响应时间满足预先约定的性能阈值，TPS不再上涨且响应时间持续升高，就代表服务到达性能瓶颈。

压测结果优先保存为csv格式文件，csv文件体积更小，后续可以导入聚合报告二次分析，jtl格式文件包含完整请求详情，文件体积增长速度更快，大批量压测时不建议全程存储jtl原始数据。

jmeter如何做性能测试之分布式压测部署

单机jmeter受CPU、网卡限制，并发能力有限，多机分布式压测可以合并多台压力机的请求能力。所有压力机使用相同版本的jmeter和jdk，关闭防火墙，在压力机启动jmeter-server，主控机远程连接压力机ip和端口，主控机只下发脚本和收集结果，压力机负责发送请求。脚本里用到的csv参数文件，需要在每一台压力机相同路径下放一份，否则部分压力机会读取不到参数，出现大量请求失败。

jmeter分布式模式下，所有压力机的线程配置是叠加生效，你计算总并发数时需要把每台压力机的线程数量相加，不要只看主控机上填写的线程数值。

jmeter如何做性能测试之瓶颈定位

压测同时要采集服务端指标，CPU使用率、内存占用、数据库连接数、慢查询日志、中间件队列长度都是排查重点。TPS上不去但服务CPU占用很低，大概率瓶颈在数据库或者下游依赖接口；CPU持续满负载，瓶颈在应用本身计算逻辑；响应时间波动大，需要核对是否存在频繁GC。jmeter本身只能看到请求侧指标，无法直接定位服务内部问题，需要配合服务监控工具交叉验证。

压测完成之后，整理聚合报告数据、服务监控截图、压测场景参数，输出性能结论，明确当前系统支持的稳定并发量和性能短板。