1. 项目概述为什么需要配置业务请求比例做性能测试的朋友尤其是用Jmeter的肯定都遇到过这种场景老板或者产品经理丢过来一个需求说“咱们模拟一下真实用户使用咱们系统的场景压测一下看看”。这个“真实用户使用场景”听起来简单但细想一下问题就来了。真实用户可不是机器人只会重复点一个按钮。他们可能80%的时间在浏览商品列表15%的时间在查看商品详情只有5%的时间会真正下单支付。如果你直接用Jmeter录个脚本把所有请求浏览、详情、下单一股脑儿地放在一个线程组里让虚拟用户随机执行那压测出来的结果和真实情况可能相差十万八千里。你可能会发现数据库连接池用得飞起但订单服务却闲得发慌或者反过来。这种压测数据对于评估系统瓶颈、规划资源扩容几乎没有参考价值甚至可能产生误导。所以“配置不同业务请求比例”这个需求本质上是为了让我们的压测脚本无限逼近真实的生产流量模型。它不是Jmeter里一个花里胡哨的功能而是性能测试从“玩具阶段”迈向“工程化阶段”的关键一步。通过精确控制不同接口的调用频率我们才能构建出有意义的“综合场景”从而得到可信的压测报告为容量规划、性能调优提供坚实的数据支撑。2. 核心思路拆解Jmeter如何实现请求比例控制Jmeter本身并没有一个叫“设置比例”的按钮。实现这个目标需要我们像搭积木一样组合使用它的几个核心控制器Controller。别被“控制器”这个名字吓到你可以把它们理解成流程的指挥棒告诉Jmeter的线程虚拟用户下一步该执行哪个请求。实现比例控制主流且清晰的思路有两种它们各有优劣适用于不同的场景。2.1 方案一使用“吞吐量控制器”Throughput Controller这是最直观、我个人也最推荐新手优先掌握的方法。它的逻辑非常直白我给每个业务请求或一组请求分配一个“门票配额”。工作原理吞吐量控制器有两种模式Percent Execution百分比执行直接设置一个百分比数字比如30。那么在它管辖范围内的所有请求子节点在整个测试计划执行期间有30%的几率会被执行。Total Executions总执行次数设置一个绝对数值。这个模式通常需要配合循环控制器来理解它表示在父循环内这个控制器下的请求最多被执行多少次。为什么选择它配置简单所见即所得比例数字填上去就行心智负担小。独立可控每个控制器管理自己的比例互相之间不影响。调整“浏览商品”的比例不会牵连到“下单支付”。易于理解测试报告里看到的数据可以很直观地和控制器设置的比例进行对照验证。2.2 方案二使用“随机控制器”Random Controller “随机顺序控制器”Random Order Controller这个方案更贴近“随机但按权重”的思想。它通常需要结合“权重”的概念来配置。工作原理随机控制器Random Controller它下面的所有子元件比如多个“简单控制器”每次执行时随机挑选一个来运行。如果子元件权重相同则每个被选中的概率均等。如何体现比例关键就在这里。我们可以通过给不同的“简单控制器”里面包裹着具体的HTTP请求设置不同的“权重”来间接实现比例。虽然Jmeter的GUI上没有直接的“权重”输入框但我们可以通过一种约定俗成的方式利用线程组的“线程属性”或配合“计数器”来模拟。更常见的做法是将不同比例的请求放到不同的“随机控制器”或“简单控制器”下然后通过控制这些控制器的执行次数比如放在循环次数不同的循环控制器里来实现宏观上的比例。但这种方法的控制精度和直观性不如吞吐量控制器。为什么有时选择它更真实的随机性在某些需要完全无规律、但总体符合某个分布的场景下随机控制器可能更合适。旧脚本兼容一些历史遗留的测试脚本可能采用了这种结构。实操心得 对于绝大多数“按明确比例配置业务请求”的场景请毫不犹豫地选择“吞吐量控制器百分比模式”。它就像一把精准的尺子而“随机权重”的方法更像是一把需要反复校准的弹簧秤。在工程实践中清晰、可维护、易解释远比一点点的“随机真实性”更重要。除非你有非常特殊的场景要求否则吞吐量控制器是你的首选。3. 详细配置与实操步骤下面我将以一个经典的电商场景为例带你一步步搭建一个比例可控的压测脚本。我们的目标是模拟浏览列表60%、查看详情30%、加入购物车7%、提交订单3%这样一个用户行为模型。3.1 环境与脚本基础准备首先确保你的Jmeter已经安装好。这里有个小坑需要注意Jmeter是纯Java应用它的性能和你本机的Java环境JDK版本直接相关。做压测尤其是高并发压测强烈建议使用JDK 8或JDK 11的LTS版本并且使用Server模式启动Jmeter在jmeter.bat或jmeter.sh脚本中可以找到JVM_ARGS添加-server参数这能带来一定的性能提升。创建线程组打开Jmeter右键“测试计划” - “添加” - “线程用户” - “线程组”。这里我们设置线程数用户100 模拟100个并发用户Ramp-Up时间秒60 在60秒内逐步启动这100个用户避免对系统造成瞬时致命冲击循环次数勾选“永远” 由调度器或手动控制停止录制或添加HTTP请求为你需要压测的四个接口/api/list,/api/detail,/api/cart,/api/order分别添加四个“HTTP请求”采样器。确保每个请求的服务器名称、端口、路径、方法GET/POST以及必要的参数如商品ID都正确配置。建议为每个采样器起一个清晰的名字如“01_浏览商品列表”、“02_查看商品详情”等。注意在添加参数时特别是商品ID这类需要变化的参数务必使用Jmeter的变量或函数如${__Random()},${__CSVRead()},${__P()}来模拟不同用户操作不同数据避免所有请求都命中同一个商品导致缓存过热无法反映真实数据库压力。这是很多新手容易忽略但对压测真实性至关重要的一步。3.2 使用吞吐量控制器配置比例现在进入核心环节。我们不直接把HTTP请求放在线程组下而是通过吞吐量控制器来管理。添加吞吐量控制器右键点击“线程组” - “添加” - “逻辑控制器” - “吞吐量控制器”。配置第一个控制器浏览列表 60%将命名为“01_浏览商品列表”的HTTP请求采样器拖动到这个吞吐量控制器下面成为其子节点。选中该吞吐量控制器在右侧面板中名称改为“比例控制_浏览列表_60%”Throughput设置为60Percent Execution选择TruePer User保持False这里很重要。如果设为True比例是针对每个虚拟用户单独计算的可能会偏离总体比例。我们通常需要全局比例所以选False。如法炮制在“线程组”下再添加三个吞吐量控制器分别命名为“比例控制_查看详情_30%”、“比例控制_加入购物车_7%”、“比例控制_提交订单_3%”并将对应的HTTP请求采样器拖入其中Throughput分别设置为30, 7, 3。此时你的线程组结构应该类似于线程组 (Thread Group) ├── 吞吐量控制器 (比例控制_浏览列表_60%) │ └── HTTP请求 (01_浏览商品列表) ├── 吞吐量控制器 (比例控制_查看详情_30%) │ └── HTTP请求 (02_查看商品详情) ├── 吞吐量控制器 (比例控制_加入购物车_7%) │ └── HTTP请求 (03_加入购物车) └── 吞吐量控制器 (比例控制_提交订单_3%) └── HTTP请求 (04_提交订单)3.3 添加逻辑思考时间Think Time真实用户操作之间有间隔。在性能测试中我们使用“定时器”来模拟这个间隔也称为思考时间。添加高斯随机定时器右键点击“线程组” - “添加” - “定时器” - “高斯随机定时器”。配置参数偏差Deviation300 单位毫秒固定延迟偏移Constant Delay Offset1000 单位毫秒这个配置表示每次请求后会等待一个时间这个时间以1000毫秒为中心进行标准差为300毫秒的正态分布随机波动。这样比固定等待1秒更真实。重要提示定时器的位置影响很大。如果像上面这样直接加在线程组下那么每个吞吐量控制器执行前后都会生效。如果你想模拟的是“每个业务操作完成后用户思考一下”那么应该把定时器分别添加到每个HTTP请求采样器之后或者作为吞吐量控制器的兄弟节点但顺序在后。这需要根据你的业务场景来设计。3.4 添加监听器查看结果配置好后我们需要验证比例是否生效并查看压测结果。添加聚合报告右键“线程组” - “添加” - “监听器” - “聚合报告”。这是最常用的概览性报告会显示每个请求的平均响应时间、吞吐量TPS/QPS、错误率等。添加查看结果树同样路径添加“查看结果树”。注意这个监听器非常消耗内存仅在调试脚本时使用正式压测前务必禁用或删除否则会很快导致Jmeter内存溢出OOM。添加Transactions per Second右键“线程组” - “添加” - “监听器” - “Transactions per Second”。这个图表可以实时看到每秒完成的交易数即吞吐量是观察系统性能变化的利器。3.5 执行测试与比例验证点击工具栏的绿色开始按钮运行测试。运行一段时间后比如1-2分钟停止测试。如何验证比例是否正确去查看“聚合报告”。重点关注每个请求的“样本数”Samples。理论上在运行时间足够长、样本量足够大的情况下四个请求的样本数比例应该接近60:30:7:3。你可以计算一下(浏览列表样本数) / (总样本数) ≈ 60%(查看详情样本数) / (总样本数) ≈ 30%... 以此类推。由于随机性和定时器的存在可能会有微小偏差比如59.5%、30.3%但只要偏差不大例如±2%以内就说明配置是成功的。如果偏差巨大请检查吞吐量控制器的“Per User”设置以及是否有其他逻辑控制器如循环控制器、仅一次控制器干扰了执行流。4. 高级技巧与复杂场景应对掌握了基础配置我们来看看一些更复杂但实际工作中一定会遇到的情况。4.1 模拟登录用户与用户状态保持很多业务场景要求用户先登录。我们需要处理Cookie或Token。处理登录在线程组最前面添加一个“仅一次控制器”Once Only Controller里面放登录请求HTTP Request。这样每个虚拟用户线程在启动时只会执行一次登录。提取Token在登录请求后添加一个“JSON提取器”如果返回JSON或“正则表达式提取器”从登录响应中提取出token或sessionId。传递Token在后续的所有业务请求浏览、详情、下单中在“HTTP信息头管理器”里添加一个头比如Authorization: Bearer ${token}其中${token}就是你提取的变量。这样每个虚拟用户就用自己的身份在操作了。4.2 参数化与数据关联这是让压测脚本“活”起来的关键。你不能让100个用户都去浏览同一个商品ID。使用CSV数据文件这是最强大的方式。创建一个CSV文件比如test_data.csv里面有多列数据如product_id,user_id,sku_id等。在线程组下添加“CSV数据文件设置”配置元件。指定文件名、文件编码UTF-8、变量名称如PRODUCT_ID, USER_ID、是否遇到文件结束符循环读取等。在HTTP请求中路径或参数里就可以使用${PRODUCT_ID}来引用。重要技巧将“CSV数据文件设置”的“共享模式”设置为“所有线程”这样所有虚拟用户共享同一份数据文件但通过“循环”设置可以模拟不同用户取到不同数据。如果设置为“当前线程”则每个线程会独立打开一个文件句柄对内存和文件IO有影响。使用随机函数对于简单的随机数可以直接用Jmeter内置函数。在参数值中填入${__Random(1000,9999,)}可以生成1000到9999的随机数。4.3 比例的动态调整与模块化有时我们想测试不同时间段流量比例不同的场景比如白天浏览多晚上下单多。使用“模块控制器”你可以将不同比例的配置即一组吞吐量控制器和请求保存为独立的“测试片段”。然后在主线程组中使用“模块控制器”在运行时动态引用这些片段。配合“定时器”和“逻辑控制器”你可以使用“吞吐量整形器”Throughput Shaping Timer或“精确吞吐量定时器”Precise Throughput Timer来更精细地控制不同时间段的吞吐量目标从而实现宏观上业务比例随时间变化的效果。但这属于更高级的流量模型塑造范畴。4.4 一个请求包含多个子步骤的比例控制有时候一个业务操作如下单本身包含多个连续的HTTP调用查库存、扣库存、生成订单。我们希望这个“下单业务”整体占3%但内部的子步骤是100%顺序执行。解决方案将“提交订单”这个HTTP请求替换为一个“简单控制器”Simple Controller。在这个简单控制器内按顺序放置“查库存”、“扣库存”、“生成订单”三个HTTP请求。然后将整个“简单控制器”作为一个整体放入一个吞吐量控制器3%之下。这样每次命中这3%的比例时就会完整地执行下单流程中的所有子步骤。5. 常见问题排查与性能优化在实际操作中你肯定会遇到各种问题。这里记录几个我踩过的坑和解决方案。5.1 比例严重失调某个请求几乎不执行可能原因1吞吐量控制器模式错误。最常见的就是错误地将“Percent Execution”设为了False而“Throughput”值又设置得很小比如3。在“Total Executions”模式下这个数字是绝对执行次数在大量循环中占比会极小。解决确认勾选了“Percent Execution: True”。可能原因2逻辑控制器嵌套错误。比如你把吞吐量控制器放在了“循环控制器”内部而循环次数又很少。或者你的请求被放在了“仅一次控制器”里。解决检查脚本的控制器结构树确保吞吐量控制器位于线程组的直接子层级或者在一个会反复执行的逻辑块内。可能原因3请求本身失败。如果某个请求因为参数错误、接口不通等原因一直失败Jmeter的默认行为取决于配置可能会提前终止该线程的该次迭代导致该请求样本数极少。解决使用“查看结果树”调试确保每个请求都能成功得到响应如HTTP 200。5.2 Jmeter自身成为瓶颈压不上去当你增加线程数后发现TPS不升反降或者响应时间剧增而服务器资源CPU、内存、网络还很空闲那很可能是Jmeter单机性能到顶了。优化Jmeter配置修改jmeter.batWindows或jmeterLinux/Mac中的JVM参数。关键参数HEAP-Xms4g -Xmx4g -XX:MaxMetaspaceSize512m将堆内存-Xms和-Xmx根据你机器内存调整比如16G内存的机器可以设到-Xms8g -Xmx8g。注意不要设置得超过物理内存的70%。禁用所有不必要的监听器特别是“查看结果树”和“用表格查看结果”。只保留“聚合报告”和“TPS”等轻量级监听器。使用命令行非GUI模式运行压测jmeter -n -t your_test.jmx -l result.jtl。这能节省大量GUI渲染开销。采用分布式压测这是解决单机瓶颈的根本方法。在多台机器压力机上启动Jmeter-Server由一台控制机Jmeter统一调度。这样可以将负载分散。5.3 如何验证“综合场景”的真实性配置好了比例压测也跑了数据怎么才算可信与生产监控数据对比如果你有生产环境的APM应用性能监控工具如SkyWalking、Pinpoint或者监控系统如PrometheusGrafana去查看生产环境中各个接口的调用量QPS分布。用这个分布来校准你压测脚本中的比例。这是最理想的方式。分析业务日志通过分析生产服务器的业务日志统计不同接口的调用频率也能得到一个近似的比例。审视响应时间分布在压测报告中不仅看平均响应时间更要看90分位、95分位、99分位90%ile, 95%ile, 99%ile的响应时间。如果某个接口的99分位时间异常高即使比例很小也可能成为系统的“短板”拖累整体体验。综合场景压测的价值之一就是发现这种在单一接口压测中不易暴露的问题。5.4 资源监控与瓶颈定位压测时一定要同时监控被压测服务器的资源使用情况。系统层面使用topLinux、htop、vmstat、iostat等命令或nmon这样的工具监控CPU使用率、内存使用量、磁盘IO、网络带宽。中间件层面数据库监控连接数、慢查询、锁等待。可以使用SHOW PROCESSLIST;、SHOW ENGINE INNODB STATUS;等命令。Redis监控内存、连接数、命中率、慢查询。消息队列监控堆积情况、消费速率。应用层面通过应用的监控指标如JVM的GC频率、线程池状态或APM工具定位到具体代码瓶颈。一个典型的瓶颈定位流程压测时发现TPS上不去响应时间变长。首先看服务器CPU是否打满。如果CPU空闲看数据库服务器CPU和磁盘IO。如果数据库也空闲看应用服务器和数据库之间的网络延迟。如果网络正常看应用日志是否有大量错误或等待。最后结合Jmeter的聚合报告看是哪个接口的响应时间最先开始增长往往那就是瓶颈的起点。配置不同业务请求的比例是Jmeter从功能测试工具升级为性能工程利器的标志性技能。它要求测试人员不仅懂工具更要懂业务、懂系统架构。记住没有一成不变的比例最好的比例模型来源于对生产流量持续不断的观察和分析。每次压测都是一次对系统认知的深化和对流量模型的修正。当你能够用脚本精准地模拟出凌晨的抢购洪峰或是工作日的平稳流量时你提供的压测报告才会真正成为开发、运维和架构师眼中值得信赖的决策依据。
JMeter性能测试：如何精准配置业务请求比例模拟真实流量
1. 项目概述为什么需要配置业务请求比例做性能测试的朋友尤其是用Jmeter的肯定都遇到过这种场景老板或者产品经理丢过来一个需求说“咱们模拟一下真实用户使用咱们系统的场景压测一下看看”。这个“真实用户使用场景”听起来简单但细想一下问题就来了。真实用户可不是机器人只会重复点一个按钮。他们可能80%的时间在浏览商品列表15%的时间在查看商品详情只有5%的时间会真正下单支付。如果你直接用Jmeter录个脚本把所有请求浏览、详情、下单一股脑儿地放在一个线程组里让虚拟用户随机执行那压测出来的结果和真实情况可能相差十万八千里。你可能会发现数据库连接池用得飞起但订单服务却闲得发慌或者反过来。这种压测数据对于评估系统瓶颈、规划资源扩容几乎没有参考价值甚至可能产生误导。所以“配置不同业务请求比例”这个需求本质上是为了让我们的压测脚本无限逼近真实的生产流量模型。它不是Jmeter里一个花里胡哨的功能而是性能测试从“玩具阶段”迈向“工程化阶段”的关键一步。通过精确控制不同接口的调用频率我们才能构建出有意义的“综合场景”从而得到可信的压测报告为容量规划、性能调优提供坚实的数据支撑。2. 核心思路拆解Jmeter如何实现请求比例控制Jmeter本身并没有一个叫“设置比例”的按钮。实现这个目标需要我们像搭积木一样组合使用它的几个核心控制器Controller。别被“控制器”这个名字吓到你可以把它们理解成流程的指挥棒告诉Jmeter的线程虚拟用户下一步该执行哪个请求。实现比例控制主流且清晰的思路有两种它们各有优劣适用于不同的场景。2.1 方案一使用“吞吐量控制器”Throughput Controller这是最直观、我个人也最推荐新手优先掌握的方法。它的逻辑非常直白我给每个业务请求或一组请求分配一个“门票配额”。工作原理吞吐量控制器有两种模式Percent Execution百分比执行直接设置一个百分比数字比如30。那么在它管辖范围内的所有请求子节点在整个测试计划执行期间有30%的几率会被执行。Total Executions总执行次数设置一个绝对数值。这个模式通常需要配合循环控制器来理解它表示在父循环内这个控制器下的请求最多被执行多少次。为什么选择它配置简单所见即所得比例数字填上去就行心智负担小。独立可控每个控制器管理自己的比例互相之间不影响。调整“浏览商品”的比例不会牵连到“下单支付”。易于理解测试报告里看到的数据可以很直观地和控制器设置的比例进行对照验证。2.2 方案二使用“随机控制器”Random Controller “随机顺序控制器”Random Order Controller这个方案更贴近“随机但按权重”的思想。它通常需要结合“权重”的概念来配置。工作原理随机控制器Random Controller它下面的所有子元件比如多个“简单控制器”每次执行时随机挑选一个来运行。如果子元件权重相同则每个被选中的概率均等。如何体现比例关键就在这里。我们可以通过给不同的“简单控制器”里面包裹着具体的HTTP请求设置不同的“权重”来间接实现比例。虽然Jmeter的GUI上没有直接的“权重”输入框但我们可以通过一种约定俗成的方式利用线程组的“线程属性”或配合“计数器”来模拟。更常见的做法是将不同比例的请求放到不同的“随机控制器”或“简单控制器”下然后通过控制这些控制器的执行次数比如放在循环次数不同的循环控制器里来实现宏观上的比例。但这种方法的控制精度和直观性不如吞吐量控制器。为什么有时选择它更真实的随机性在某些需要完全无规律、但总体符合某个分布的场景下随机控制器可能更合适。旧脚本兼容一些历史遗留的测试脚本可能采用了这种结构。实操心得 对于绝大多数“按明确比例配置业务请求”的场景请毫不犹豫地选择“吞吐量控制器百分比模式”。它就像一把精准的尺子而“随机权重”的方法更像是一把需要反复校准的弹簧秤。在工程实践中清晰、可维护、易解释远比一点点的“随机真实性”更重要。除非你有非常特殊的场景要求否则吞吐量控制器是你的首选。3. 详细配置与实操步骤下面我将以一个经典的电商场景为例带你一步步搭建一个比例可控的压测脚本。我们的目标是模拟浏览列表60%、查看详情30%、加入购物车7%、提交订单3%这样一个用户行为模型。3.1 环境与脚本基础准备首先确保你的Jmeter已经安装好。这里有个小坑需要注意Jmeter是纯Java应用它的性能和你本机的Java环境JDK版本直接相关。做压测尤其是高并发压测强烈建议使用JDK 8或JDK 11的LTS版本并且使用Server模式启动Jmeter在jmeter.bat或jmeter.sh脚本中可以找到JVM_ARGS添加-server参数这能带来一定的性能提升。创建线程组打开Jmeter右键“测试计划” - “添加” - “线程用户” - “线程组”。这里我们设置线程数用户100 模拟100个并发用户Ramp-Up时间秒60 在60秒内逐步启动这100个用户避免对系统造成瞬时致命冲击循环次数勾选“永远” 由调度器或手动控制停止录制或添加HTTP请求为你需要压测的四个接口/api/list,/api/detail,/api/cart,/api/order分别添加四个“HTTP请求”采样器。确保每个请求的服务器名称、端口、路径、方法GET/POST以及必要的参数如商品ID都正确配置。建议为每个采样器起一个清晰的名字如“01_浏览商品列表”、“02_查看商品详情”等。注意在添加参数时特别是商品ID这类需要变化的参数务必使用Jmeter的变量或函数如${__Random()},${__CSVRead()},${__P()}来模拟不同用户操作不同数据避免所有请求都命中同一个商品导致缓存过热无法反映真实数据库压力。这是很多新手容易忽略但对压测真实性至关重要的一步。3.2 使用吞吐量控制器配置比例现在进入核心环节。我们不直接把HTTP请求放在线程组下而是通过吞吐量控制器来管理。添加吞吐量控制器右键点击“线程组” - “添加” - “逻辑控制器” - “吞吐量控制器”。配置第一个控制器浏览列表 60%将命名为“01_浏览商品列表”的HTTP请求采样器拖动到这个吞吐量控制器下面成为其子节点。选中该吞吐量控制器在右侧面板中名称改为“比例控制_浏览列表_60%”Throughput设置为60Percent Execution选择TruePer User保持False这里很重要。如果设为True比例是针对每个虚拟用户单独计算的可能会偏离总体比例。我们通常需要全局比例所以选False。如法炮制在“线程组”下再添加三个吞吐量控制器分别命名为“比例控制_查看详情_30%”、“比例控制_加入购物车_7%”、“比例控制_提交订单_3%”并将对应的HTTP请求采样器拖入其中Throughput分别设置为30, 7, 3。此时你的线程组结构应该类似于线程组 (Thread Group) ├── 吞吐量控制器 (比例控制_浏览列表_60%) │ └── HTTP请求 (01_浏览商品列表) ├── 吞吐量控制器 (比例控制_查看详情_30%) │ └── HTTP请求 (02_查看商品详情) ├── 吞吐量控制器 (比例控制_加入购物车_7%) │ └── HTTP请求 (03_加入购物车) └── 吞吐量控制器 (比例控制_提交订单_3%) └── HTTP请求 (04_提交订单)3.3 添加逻辑思考时间Think Time真实用户操作之间有间隔。在性能测试中我们使用“定时器”来模拟这个间隔也称为思考时间。添加高斯随机定时器右键点击“线程组” - “添加” - “定时器” - “高斯随机定时器”。配置参数偏差Deviation300 单位毫秒固定延迟偏移Constant Delay Offset1000 单位毫秒这个配置表示每次请求后会等待一个时间这个时间以1000毫秒为中心进行标准差为300毫秒的正态分布随机波动。这样比固定等待1秒更真实。重要提示定时器的位置影响很大。如果像上面这样直接加在线程组下那么每个吞吐量控制器执行前后都会生效。如果你想模拟的是“每个业务操作完成后用户思考一下”那么应该把定时器分别添加到每个HTTP请求采样器之后或者作为吞吐量控制器的兄弟节点但顺序在后。这需要根据你的业务场景来设计。3.4 添加监听器查看结果配置好后我们需要验证比例是否生效并查看压测结果。添加聚合报告右键“线程组” - “添加” - “监听器” - “聚合报告”。这是最常用的概览性报告会显示每个请求的平均响应时间、吞吐量TPS/QPS、错误率等。添加查看结果树同样路径添加“查看结果树”。注意这个监听器非常消耗内存仅在调试脚本时使用正式压测前务必禁用或删除否则会很快导致Jmeter内存溢出OOM。添加Transactions per Second右键“线程组” - “添加” - “监听器” - “Transactions per Second”。这个图表可以实时看到每秒完成的交易数即吞吐量是观察系统性能变化的利器。3.5 执行测试与比例验证点击工具栏的绿色开始按钮运行测试。运行一段时间后比如1-2分钟停止测试。如何验证比例是否正确去查看“聚合报告”。重点关注每个请求的“样本数”Samples。理论上在运行时间足够长、样本量足够大的情况下四个请求的样本数比例应该接近60:30:7:3。你可以计算一下(浏览列表样本数) / (总样本数) ≈ 60%(查看详情样本数) / (总样本数) ≈ 30%... 以此类推。由于随机性和定时器的存在可能会有微小偏差比如59.5%、30.3%但只要偏差不大例如±2%以内就说明配置是成功的。如果偏差巨大请检查吞吐量控制器的“Per User”设置以及是否有其他逻辑控制器如循环控制器、仅一次控制器干扰了执行流。4. 高级技巧与复杂场景应对掌握了基础配置我们来看看一些更复杂但实际工作中一定会遇到的情况。4.1 模拟登录用户与用户状态保持很多业务场景要求用户先登录。我们需要处理Cookie或Token。处理登录在线程组最前面添加一个“仅一次控制器”Once Only Controller里面放登录请求HTTP Request。这样每个虚拟用户线程在启动时只会执行一次登录。提取Token在登录请求后添加一个“JSON提取器”如果返回JSON或“正则表达式提取器”从登录响应中提取出token或sessionId。传递Token在后续的所有业务请求浏览、详情、下单中在“HTTP信息头管理器”里添加一个头比如Authorization: Bearer ${token}其中${token}就是你提取的变量。这样每个虚拟用户就用自己的身份在操作了。4.2 参数化与数据关联这是让压测脚本“活”起来的关键。你不能让100个用户都去浏览同一个商品ID。使用CSV数据文件这是最强大的方式。创建一个CSV文件比如test_data.csv里面有多列数据如product_id,user_id,sku_id等。在线程组下添加“CSV数据文件设置”配置元件。指定文件名、文件编码UTF-8、变量名称如PRODUCT_ID, USER_ID、是否遇到文件结束符循环读取等。在HTTP请求中路径或参数里就可以使用${PRODUCT_ID}来引用。重要技巧将“CSV数据文件设置”的“共享模式”设置为“所有线程”这样所有虚拟用户共享同一份数据文件但通过“循环”设置可以模拟不同用户取到不同数据。如果设置为“当前线程”则每个线程会独立打开一个文件句柄对内存和文件IO有影响。使用随机函数对于简单的随机数可以直接用Jmeter内置函数。在参数值中填入${__Random(1000,9999,)}可以生成1000到9999的随机数。4.3 比例的动态调整与模块化有时我们想测试不同时间段流量比例不同的场景比如白天浏览多晚上下单多。使用“模块控制器”你可以将不同比例的配置即一组吞吐量控制器和请求保存为独立的“测试片段”。然后在主线程组中使用“模块控制器”在运行时动态引用这些片段。配合“定时器”和“逻辑控制器”你可以使用“吞吐量整形器”Throughput Shaping Timer或“精确吞吐量定时器”Precise Throughput Timer来更精细地控制不同时间段的吞吐量目标从而实现宏观上业务比例随时间变化的效果。但这属于更高级的流量模型塑造范畴。4.4 一个请求包含多个子步骤的比例控制有时候一个业务操作如下单本身包含多个连续的HTTP调用查库存、扣库存、生成订单。我们希望这个“下单业务”整体占3%但内部的子步骤是100%顺序执行。解决方案将“提交订单”这个HTTP请求替换为一个“简单控制器”Simple Controller。在这个简单控制器内按顺序放置“查库存”、“扣库存”、“生成订单”三个HTTP请求。然后将整个“简单控制器”作为一个整体放入一个吞吐量控制器3%之下。这样每次命中这3%的比例时就会完整地执行下单流程中的所有子步骤。5. 常见问题排查与性能优化在实际操作中你肯定会遇到各种问题。这里记录几个我踩过的坑和解决方案。5.1 比例严重失调某个请求几乎不执行可能原因1吞吐量控制器模式错误。最常见的就是错误地将“Percent Execution”设为了False而“Throughput”值又设置得很小比如3。在“Total Executions”模式下这个数字是绝对执行次数在大量循环中占比会极小。解决确认勾选了“Percent Execution: True”。可能原因2逻辑控制器嵌套错误。比如你把吞吐量控制器放在了“循环控制器”内部而循环次数又很少。或者你的请求被放在了“仅一次控制器”里。解决检查脚本的控制器结构树确保吞吐量控制器位于线程组的直接子层级或者在一个会反复执行的逻辑块内。可能原因3请求本身失败。如果某个请求因为参数错误、接口不通等原因一直失败Jmeter的默认行为取决于配置可能会提前终止该线程的该次迭代导致该请求样本数极少。解决使用“查看结果树”调试确保每个请求都能成功得到响应如HTTP 200。5.2 Jmeter自身成为瓶颈压不上去当你增加线程数后发现TPS不升反降或者响应时间剧增而服务器资源CPU、内存、网络还很空闲那很可能是Jmeter单机性能到顶了。优化Jmeter配置修改jmeter.batWindows或jmeterLinux/Mac中的JVM参数。关键参数HEAP-Xms4g -Xmx4g -XX:MaxMetaspaceSize512m将堆内存-Xms和-Xmx根据你机器内存调整比如16G内存的机器可以设到-Xms8g -Xmx8g。注意不要设置得超过物理内存的70%。禁用所有不必要的监听器特别是“查看结果树”和“用表格查看结果”。只保留“聚合报告”和“TPS”等轻量级监听器。使用命令行非GUI模式运行压测jmeter -n -t your_test.jmx -l result.jtl。这能节省大量GUI渲染开销。采用分布式压测这是解决单机瓶颈的根本方法。在多台机器压力机上启动Jmeter-Server由一台控制机Jmeter统一调度。这样可以将负载分散。5.3 如何验证“综合场景”的真实性配置好了比例压测也跑了数据怎么才算可信与生产监控数据对比如果你有生产环境的APM应用性能监控工具如SkyWalking、Pinpoint或者监控系统如PrometheusGrafana去查看生产环境中各个接口的调用量QPS分布。用这个分布来校准你压测脚本中的比例。这是最理想的方式。分析业务日志通过分析生产服务器的业务日志统计不同接口的调用频率也能得到一个近似的比例。审视响应时间分布在压测报告中不仅看平均响应时间更要看90分位、95分位、99分位90%ile, 95%ile, 99%ile的响应时间。如果某个接口的99分位时间异常高即使比例很小也可能成为系统的“短板”拖累整体体验。综合场景压测的价值之一就是发现这种在单一接口压测中不易暴露的问题。5.4 资源监控与瓶颈定位压测时一定要同时监控被压测服务器的资源使用情况。系统层面使用topLinux、htop、vmstat、iostat等命令或nmon这样的工具监控CPU使用率、内存使用量、磁盘IO、网络带宽。中间件层面数据库监控连接数、慢查询、锁等待。可以使用SHOW PROCESSLIST;、SHOW ENGINE INNODB STATUS;等命令。Redis监控内存、连接数、命中率、慢查询。消息队列监控堆积情况、消费速率。应用层面通过应用的监控指标如JVM的GC频率、线程池状态或APM工具定位到具体代码瓶颈。一个典型的瓶颈定位流程压测时发现TPS上不去响应时间变长。首先看服务器CPU是否打满。如果CPU空闲看数据库服务器CPU和磁盘IO。如果数据库也空闲看应用服务器和数据库之间的网络延迟。如果网络正常看应用日志是否有大量错误或等待。最后结合Jmeter的聚合报告看是哪个接口的响应时间最先开始增长往往那就是瓶颈的起点。配置不同业务请求的比例是Jmeter从功能测试工具升级为性能工程利器的标志性技能。它要求测试人员不仅懂工具更要懂业务、懂系统架构。记住没有一成不变的比例最好的比例模型来源于对生产流量持续不断的观察和分析。每次压测都是一次对系统认知的深化和对流量模型的修正。当你能够用脚本精准地模拟出凌晨的抢购洪峰或是工作日的平稳流量时你提供的压测报告才会真正成为开发、运维和架构师眼中值得信赖的决策依据。
