企业官网建设流程全解析

1. JMeter请求重复问题现象解析

最近在压测过程中发现一个奇怪现象：JMeter脚本明明设置了1次迭代，结果树中却偶尔出现两次完全相同的请求记录。这种情况在HTTP/HTTPS协议测试中尤为常见，特别是当被测系统涉及重定向或安全验证时。作为从业十年的性能测试工程师，我整理了这个问题背后的六种典型场景和解决方案。

注意：请求重复并非JMeter的BUG，而是特定配置与服务器响应共同作用的结果。理解其原理才能正确优化测试脚本。

2. 核心原因深度排查

2.1 自动重定向引发的"假重复"

JMeter默认会跟随HTTP 3xx重定向（可在HTTP请求高级选项卡中配置）。当服务器返回302/301时：

1. 首次请求返回重定向响应
2. JMeter自动发起第二次请求到新地址
3. 结果树中显示两条记录（状态码不同）

验证方法：在View Results Tree中检查：

• 第一条请求状态码为3xx
• 第二条请求URL可能发生变化
• 使用"Redirect automatically"选项控制此行为

2.2 HTTPS证书校验导致的二次握手

未正确配置SSL管理器时：

1. 首次HTTPS握手失败
2. JMeter自动重试连接
3. 表现为同一请求发送两次

解决方案：

# 添加证书到JMeter信任库 keytool -import -alias server_cert -keystore /path/to/jmeter/bin/ApacheJMeterTemporaryRootCA.crt

2.3 监听器配置不当造成的显示异常

某些监听器（如Aggregate Report）会统计采样器的实际执行次数，而View Results Tree可能显示预处理前后的请求。典型场景包括：

• 前置处理器修改了请求参数
• 后置处理器触发了额外操作

2.4 循环控制器与线程组配置冲突

当同时满足：

1. 线程组设置1次迭代
2. 采样器放在循环控制器内
3. 循环次数>1时 会导致实际请求次数翻倍

正确配置示例：

Thread Group └─ Loop Controller (loops=1) └─ HTTP Request

2.5 网络抖动触发的重试机制

在低质量网络环境下：

1. 首次请求超时（无响应）
2. JMeter根据retry.count参数自动重试
3. 最终成功但显示两条记录

优化建议：

# 修改jmeter.properties httpclient4.retrycount=0 # 禁用重试 httpclient4.timeout=30000 # 合理设置超时

2.6 采样器误放在多个逻辑控制器中

嵌套使用Transaction Controller、Simple Controller等组件时，可能无意中创建了多级执行路径。建议使用Test Fragment模块化设计测试计划。

3. 问题诊断四步法

3.1 确认基础配置

1. 检查线程组迭代次数
2. 验证所有控制器的循环次数
3. 确认HTTP请求高级选项：
   • Redirect Automatically：是否勾选
   • Use keepAlive：连接复用设置

3.2 分析服务器日志

通过对比JMeter请求时间戳与服务器访问日志，可以明确：

• 是否真的收到两次请求
• 两次请求的时间间隔
• 请求参数是否完全相同

3.3 启用详细日志

在jmeter.bat中添加：

log_level.jmeter=DEBUG log_level.jmeter.protocol.http=DEBUG

日志会显示每次请求的详细生命周期。

3.4 使用过滤器定位

在View Results Tree中添加正则表达式过滤器：

Filter：\d+-\d+ Regex：^(?!.*(Redirect|Retry)).*$

这样可以隐藏自动重定向和重试产生的请求。

4. 五种典型场景解决方案

4.1 重定向场景优化

对于需要测试重定向逻辑的情况：

1. 取消勾选"Redirect automatically"
2. 手动添加HTTP请求默认值
3. 使用正则表达式提取Location头
4. 构造第二个请求验证跳转

4.2 文件上传特殊处理

当测试文件上传接口时：

1. 设置Use multipart/form-data
2. 添加HTTP头管理器：

   Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

3. 禁用内容编码

4.3 动态参数去重

使用__Random()等函数时：

1. 在Test Plan中勾选"Functional Mode"
2. 添加Debug Sampler验证参数值
3. 使用${__V(var)}引用动态变量

4.4 分布式测试同步

在Master-Slave模式下：

1. 确保所有节点时间同步
2. 使用__machineIP()识别请求来源
3. 在服务器端记录X-Forwarded-For头

4.5 结果聚合分析

使用Aggregate Report时：

1. 勾选"Ignore samples where response time > threshold"
2. 设置合理的误差阈值
3. 配合Response Assertion过滤无效请求

5. 高级调试技巧

5.1 使用JSR223断言

if (prev.getSampleCount() > 1) { log.warn("Duplicate request detected: " + prev.getSampleLabel()) SampleResult.setIgnore() }

这段脚本会自动标记重复请求。

5.2 流量镜像对比

1. 配置TCP镜像代理（如mitmproxy）
2. 对比JMeter发送和服务器接收的原始报文
3. 分析TCP序列号确认是否重复传输

5.3 线程转储分析

当JMeter自身出现异常时：

jstack -l <JMeter_PID> > thread_dump.log

检查是否有阻塞的I/O操作。

5.4 内存分析

使用VisualVM监控：

1. HTTPClient连接池状态
2. SSL会话缓存大小
3. 请求对象生命周期

6. 性能优化建议

1. 连接池配置：

   httpclient4.time_to_live=60000 httpclient4.max_total=200

2. DNS缓存：

   dns_cache_manager.max_size=500 dns_cache_manager.clear_each_iteration=false

3. 结果收集优化：
   • 禁用不需要的监听器
   • 使用Simple Data Writer替代GUI组件
   • 设置合理的Sample保存数量

7. 常见误区排查

1. 误判Keep-Alive：持久连接不等于重复请求，可通过Wireshark抓包验证TCP会话
2. 忽略Cookie影响：某些服务会用Set-Cookie触发客户端重试
3. 未考虑负载均衡：不同请求可能打到不同后端服务器
4. 时间戳精度问题：高并发下纳秒级时间戳可能造成"同时"请求假象

实际案例：某电商平台压测时出现"重复请求"，最终发现是Nginx配置了镜像流量，与JMeter无关。通过对比请求头中的X-Request-ID字段确认了该问题。