JMeter 采样器（Sampler）全指南

玖釉-2025-12-09 8:06

目录

[1. 什么是 Sampler？（核心概念）](#1. 什么是 Sampler？（核心概念）)

[2. Sampler 的执行机制（非常重要）](#2. Sampler 的执行机制（非常重要）)

[3.官方支持的主要 Sampler](#3.官方支持的主要 Sampler)

4.Sampler详细分析

[HTTP Request 全面解析](#HTTP Request 全面解析)

[一. HTTP Request 是什么？](#一. HTTP Request 是什么？)

[二. HTTP Request Sampler 的典型应用场景](#二. HTTP Request Sampler 的典型应用场景)

[三. HTTP Request 参数详解（最核心部分）](#三. HTTP Request 参数详解（最核心部分）)

[3.1 Protocol (http / https)](#3.1 Protocol (http / https))

[3.2 Method（请求方法）](#3.2 Method（请求方法）)

[3.3 Server Name or IP （域名/IP）](#3.3 Server Name or IP （域名/IP）)

[3.4 Port Number（端口）](#3.4 Port Number（端口）)

[3.5 Path（路径）](#3.5 Path（路径）)

[3.6 Parameters（请求参数）（适用于 GET、DELETE、POST、PUT）](#3.6 Parameters（请求参数）（适用于 GET、DELETE、POST、PUT）)

参数处理规则：

[3.7 Body Data（请求体）](#3.7 Body Data（请求体）)

[3.8 File Upload（文件上传）](#3.8 File Upload（文件上传）)

[四. HTTP Request 工作流程](#四. HTTP Request 工作流程)

[GraphQL HTTP Request 全面解析](#GraphQL HTTP Request 全面解析)

[一.GraphQL HTTP Request 是什么？](#一.GraphQL HTTP Request 是什么？)

[二.为什么不用普通 HTTP Request？](#二.为什么不用普通 HTTP Request？)

[三.GraphQL HTTP Request 的界面结构](#三.GraphQL HTTP Request 的界面结构)

[s.JMeter 如何将这些字段拼成实际 HTTP 请求？](#s.JMeter 如何将这些字段拼成实际 HTTP 请求？)

[五.GET 和 POST 的差异](#五.GET 和 POST 的差异)

[六.GraphQL HTTP Request 参数说明](#六.GraphQL HTTP Request 参数说明)

[七. 常见错误与踩坑](#七. 常见错误与踩坑)

[八.GraphQL HTTP Request 和 HTTP Request 的关系总结](#八.GraphQL HTTP Request 和 HTTP Request 的关系总结)

[AJP/1.3 Sampler 全面解析](#AJP/1.3 Sampler 全面解析)

[一.什么是 AJP/1.3？它适用于哪些场景？](#一.什么是 AJP/1.3？它适用于哪些场景？)

[二. AJP/1.3 Sampler 参数详解](#二. AJP/1.3 Sampler 参数详解)

[① Server（服务器地址）](#① Server（服务器地址）)

[② Port（端口）](#② Port（端口）)

[③ Method（请求方法）](#③ Method（请求方法）)

[④ Path（资源路径）](#④ Path（资源路径）)

[⑤ Parameters（请求参数）](#⑤ Parameters（请求参数）)

[⑥ Request Headers](#⑥ Request Headers)

[⑦ Message Body（请求体）](#⑦ Message Body（请求体）)

[⑧ Timeout（超时）](#⑧ Timeout（超时）)

[三. AJP Sampler 的优势](#三. AJP Sampler 的优势)

[四.AJP 测试注意事项](#四.AJP 测试注意事项)

[1. 必须启用 AJP Connector](#1. 必须启用 AJP Connector)

[2. 可能被防火墙或代理屏蔽](#2. 可能被防火墙或代理屏蔽)

[3. 安全风险（Ghostcat）](#3. 安全风险（Ghostcat）)

五.总结

[Access Log Sampler 全面解析](#Access Log Sampler 全面解析)

[一. Access Log Sampler 的核心功能](#一. Access Log Sampler 的核心功能)

[二. 常见适配的日志格式](#二. 常见适配的日志格式)

[三. Access Log Sampler 的界面字段说明](#三. Access Log Sampler 的界面字段说明)

[① Default Test Values（默认请求属性）](#① Default Test Values（默认请求属性）)

[② Parse Images（是否解析静态资源）](#② Parse Images（是否解析静态资源）)

[③ Parser（日志解析器）](#③ Parser（日志解析器）)

[④ Filter（可选过滤器）](#④ Filter（可选过滤器）)

[⑤ Log File（日志文件位置）](#⑤ Log File（日志文件位置）)

[四. Access Log Sampler 的执行原理](#四. Access Log Sampler 的执行原理)

[五. 使用示例：从 access.log 自动生成流量](#五. 使用示例：从 access.log 自动生成流量)

[六. 适用场景](#六. 适用场景)

[✔ 非常适用：](#✔ 非常适用：)

[✘ 不适合：](#✘ 不适合：)

[七. 总结](#七. 总结)

[FTP Request Sampler 全面解析](#FTP Request Sampler 全面解析)

[一. FTP Sampler 的作用](#一. FTP Sampler 的作用)

[二. FTP Request Sampler 参数详解](#二. FTP Request Sampler 参数详解)

[① Server Settings（服务器配置）](#① Server Settings（服务器配置）)

[② File to Retrieve or Upload（操作文件）](#② File to Retrieve or Upload（操作文件）)

[③ Use Binary Mode？（是否二进制模式）](#③ Use Binary Mode？（是否二进制模式）)

[④ Login Configuration（登录设置）](#④ Login Configuration（登录设置）)

[⑤ Other Options（其他选项）](#⑤ Other Options（其他选项）)

[三. 典型应用场景](#三. 典型应用场景)

[四. 使用 FTP Sampler 的常见问题](#四. 使用 FTP Sampler 的常见问题)

[五. 总结](#五. 总结)

[TCP Sampler 全面解析](#TCP Sampler 全面解析)

[一. TCP Sampler 是什么？](#一. TCP Sampler 是什么？)

[二. 典型应用场景](#二. 典型应用场景)

[✔ 1. 测试自定义协议服务](#✔ 1. 测试自定义协议服务)

[✔ 2. IoT 设备模拟](#✔ 2. IoT 设备模拟)

[✔ 3. 测试内网微服务网关](#✔ 3. 测试内网微服务网关)

[✔ 4. 测试 Socket Server 稳定性](#✔ 4. 测试 Socket Server 稳定性)

[三. TCP Sampler 参数详解](#三. TCP Sampler 参数详解)

[四. 典型使用示例](#四. 典型使用示例)

[五. 返回结果解析（Response）](#五. 返回结果解析（Response）)

[六. 使用 TCP Sampler 的常见注意事项](#六. 使用 TCP Sampler 的常见注意事项)

[七. 进阶：使用 TCPClientClass 扩展协议](#七. 进阶：使用 TCPClientClass 扩展协议)

[八. 总结](#八. 总结)

[Publisher Sampler 全面解析](#Publisher Sampler 全面解析)

[一. JMS Publisher 是什么？](#一. JMS Publisher 是什么？)

[二. JMS Publisher 的典型应用场景](#二. JMS Publisher 的典型应用场景)

[三. JMS Publisher 配置项详解](#三. JMS Publisher 配置项详解)

[3.1 基础设置](#3.1 基础设置)

[3.2 JMS 配置区](#3.2 JMS 配置区)

[3.3 Messaging 目标配置](#3.3 Messaging 目标配置)

[3.4 Message 内容配置](#3.4 Message 内容配置)

[3.5 JMS Headers 和 Properties](#3.5 JMS Headers 和 Properties)

[3.6 可选项](#3.6 可选项)

[四. 使用示例：发布 JSON 消息到 ActiveMQ](#四. 使用示例：发布 JSON 消息到 ActiveMQ)

[五. 性能测试最佳实践](#五. 性能测试最佳实践)

[六. 总结](#六. 总结)

[Bolt Request 使用详解：Neo4j 数据库性能测试指南](#Bolt Request 使用详解：Neo4j 数据库性能测试指南)

[一. Bolt Request 是什么？](#一. Bolt Request 是什么？)

[二. 采样器界面总览](#二. 采样器界面总览)

[三. 参数详解](#三. 参数详解)

[3.1 Name / Comments](#3.1 Name / Comments)

[3.2 Cypher Statement（Cypher 语句）](#3.2 Cypher Statement（Cypher 语句）)

[3.3 Params（查询参数，JSON 格式）](#3.3 Params（查询参数，JSON 格式）)

[3.4 Record Query Results](#3.4 Record Query Results)

[四. Options 详解](#四. Options 详解)

[4.1 Access Mode（访问模式）](#4.1 Access Mode（访问模式）)

[4.2 Database（目标数据库）](#4.2 Database（目标数据库）)

[4.3 Transaction timeout（事务超时）](#4.3 Transaction timeout（事务超时）)

[五. 常见错误与排查方法](#五. 常见错误与排查方法)

[六. 总结](#六. 总结)

[SMTP Sampler 全面指南：从邮件发送到安全认证](#SMTP Sampler 全面指南：从邮件发送到安全认证)

[一. 基本信息区](#一. 基本信息区)

[二. Server settings（服务器配置）](#二. Server settings（服务器配置）)

[三. Mail settings（邮件地址设置）](#三. Mail settings（邮件地址设置）)

[四. Auth settings（SMTP 登录认证）](#四. Auth settings（SMTP 登录认证）)

[五. Security settings（安全设置）](#五. Security settings（安全设置）)

[六. Message settings（邮件内容配置）](#六. Message settings（邮件内容配置）)

[七. Attach file(s)（附件设置）](#七. Attach file(s)（附件设置）)

[八. Additional settings（高级附加项）](#八. Additional settings（高级附加项）)

[九. 常见错误排查](#九. 常见错误排查)

[十. 总结](#十. 总结)

[Mail Reader Sampler（邮件读取采样器）](#Mail Reader Sampler（邮件读取采样器）)

[一、Mail Reader Sampler 的用途概览](#一、Mail Reader Sampler 的用途概览)

二、界面字段详解

[1. 基础信息](#1. 基础信息)

[2. 协议与连接配置](#2. 协议与连接配置)

[3. 邮件读取数量与行为控制](#3. 邮件读取数量与行为控制)

[4. 安全设置（SSL / TLS）](#4. 安全设置（SSL / TLS）)

[三、常见问题 FAQ](#三、常见问题 FAQ)

四、总结

[JDBC Request（数据库请求采样器）全面解析](#JDBC Request（数据库请求采样器）全面解析)

[一、JDBC Request 用途概览](#一、JDBC Request 用途概览)

[二、环境前置：JDBC 驱动配置（非常重要）](#二、环境前置：JDBC 驱动配置（非常重要）)

[1. 下载 JDBC Driver](#1. 下载 JDBC Driver)

[2. 将驱动放入 JMeter 的 lib 目录](#2. 将驱动放入 JMeter 的 lib 目录)

[三、JDBC Connection Configuration（数据库连接配置）](#三、JDBC Connection Configuration（数据库连接配置）)

[1. Variable Name（变量名）](#1. Variable Name（变量名）)

[2. Database URL](#2. Database URL)

[3. JDBC Driver class](#3. JDBC Driver class)

[4. Username / Password](#4. Username / Password)

[5. Max Number of Connections](#5. Max Number of Connections)

[四、JDBC Request 采样器界面详解](#四、JDBC Request 采样器界面详解)

[1. Name / Comments](#1. Name / Comments)

[2. Variable Name for created pool（连接池名称）](#2. Variable Name for created pool（连接池名称）)

[3. Query Type（查询类型）](#3. Query Type（查询类型）)

[4. SQL Query（SQL 语句）](#4. SQL Query（SQL 语句）)

[5. Parameter values（SQL 参数值）](#5. Parameter values（SQL 参数值）)

[6. Parameter types（参数类型）](#6. Parameter types（参数类型）)

[7. Result variable name（结果变量名）](#7. Result variable name（结果变量名）)

[8. Query timeout（超时）](#8. Query timeout（超时）)

五、最佳实践与性能优化

[六、常见问题 FAQ](#六、常见问题 FAQ)

七、总结

[LDAP Request](#LDAP Request)

[一、Login Configuration（登录配置）](#一、Login Configuration（登录配置）)

[二、Test Configuration（测试配置）](#二、Test Configuration（测试配置）)

[1. Add Test（添加测试）](#1. Add Test（添加测试）)

[2. Delete Test（删除测试）](#2. Delete Test（删除测试）)

[3. Search Test（搜索测试）](#3. Search Test（搜索测试）)

[4. Modify Test（修改测试）](#4. Modify Test（修改测试）)

[三、User Defined Test（自定义测试）](#三、User Defined Test（自定义测试）)

四、适用场景总结

[LDAP Extended Request ------ JMeter 最全面的 LDAP 操作采样器详解](#LDAP Extended Request —— JMeter 最全面的 LDAP 操作采样器详解)

一、界面总览

[二、Test Configuration（测试行为配置）](#二、Test Configuration（测试行为配置）)

[1. Thread Bind（线程绑定）](#1. Thread Bind（线程绑定）)

[2. Thread Unbind（线程解绑）](#2. Thread Unbind（线程解绑）)

[3. Single bind/unbind（单次绑定）](#3. Single bind/unbind（单次绑定）)

[4. Rename Entry（重命名条目）](#4. Rename Entry（重命名条目）)

[三、Test（具体 LDAP 操作类型）](#三、Test（具体 LDAP 操作类型）)

[1. Add Test（添加条目）](#1. Add Test（添加条目）)

[2. Deletion Test（删除条目）](#2. Deletion Test（删除条目）)

[3. Search Test（搜索条目）](#3. Search Test（搜索条目）)

[4. Compare（属性比对）](#4. Compare（属性比对）)

[5. Modification Test（修改条目）](#5. Modification Test（修改条目）)

四、总结

[JSR223 Sampler 全面详解](#JSR223 Sampler 全面详解)

[一、JSR223 Sampler 的定位与使用场景](#一、JSR223 Sampler 的定位与使用场景)

[1. 构建自定义协议请求](#1. 构建自定义协议请求)

[2. 实现复杂业务逻辑](#2. 实现复杂业务逻辑)

[3. 执行外部接口或工具](#3. 执行外部接口或工具)

[4. 实现流程控制](#4. 实现流程控制)

[5. 替代性能较低的 Beanshell](#5. 替代性能较低的 Beanshell)

[二、JSR223 Sampler 组件结构与参数解释](#二、JSR223 Sampler 组件结构与参数解释)

[1. Name（名称）](#1. Name（名称）)

[2. Script Language（脚本语言）](#2. Script Language（脚本语言）)

[3. Script（脚本内容）](#3. Script（脚本内容）)

[4. Parameters 与 File name（可选）](#4. Parameters 与 File name（可选）)

[5. Script compilation caching（脚本缓存）](#5. Script compilation caching（脚本缓存）)

[三、JSR223 Sampler 的执行机制](#三、JSR223 Sampler 的执行机制)

[1. Groovy：编译执行（推荐）](#1. Groovy：编译执行（推荐）)

[2. Beanshell：解释执行（非常慢）](#2. Beanshell：解释执行（非常慢）)

[3. JavaScript 等语言：性能不稳定](#3. JavaScript 等语言：性能不稳定)

[四、JSR223 中常用的内置对象](#四、JSR223 中常用的内置对象)

[五、JSR223 使用中的最佳实践](#五、JSR223 使用中的最佳实践)

[六、何时应该使用 JSR223 Sampler？](#六、何时应该使用 JSR223 Sampler？)

七、总结

[JMeter BeanShell Sampler 全面详解（不推荐，但必须了解）](#JMeter BeanShell Sampler 全面详解（不推荐，但必须了解）)

[一、BeanShell Sampler 的作用与定位](#一、BeanShell Sampler 的作用与定位)

[二、BeanShell Sampler 的典型使用场景](#二、BeanShell Sampler 的典型使用场景)

[三、BeanShell Sampler 配置项详解](#三、BeanShell Sampler 配置项详解)

[1. Name（名称）](#1. Name（名称）)

[2. Parameters（参数）](#2. Parameters（参数）)

[3. Script File（脚本文件）](#3. Script File（脚本文件）)

[4. Script（脚本内容）](#4. Script（脚本内容）)

[四、BeanShell 的执行机制（为什么慢？）](#四、BeanShell 的执行机制（为什么慢？）)

[五、BeanShell Sampler 的风险与常见问题](#五、BeanShell Sampler 的风险与常见问题)

[六、最佳实践（如果你必须使用 BeanShell）](#六、最佳实践（如果你必须使用 BeanShell）)

[七、BeanShell Sampler 是否应该继续使用？](#七、BeanShell Sampler 是否应该继续使用？)

八、总结

[Java Request Sampler 全面详解：适用于自定义协议的终极扩展方式](#Java Request Sampler 全面详解：适用于自定义协议的终极扩展方式)

[一、Java Request Sampler 的工作机制](#一、Java Request Sampler 的工作机制)

[二、Java Request 的适用场景](#二、Java Request 的适用场景)

[1. 私有协议性能测试](#1. 私有协议性能测试)

[2. 调用本地 Java 逻辑进行复杂业务流程模拟](#2. 调用本地 Java 逻辑进行复杂业务流程模拟)

[3. 测试无需网络的功能](#3. 测试无需网络的功能)

[4. 作为自定义采样器开发的过渡方式](#4. 作为自定义采样器开发的过渡方式)

[三、Java Request Sampler 配置项详解](#三、Java Request Sampler 配置项详解)

[1. Name（名称）](#1. Name（名称）)

[2. Classname（类名）](#2. Classname（类名）)

[3. Parameters（参数）](#3. Parameters（参数）)

[四、自定义 Java Sampler 的设计原则](#四、自定义 Java Sampler 的设计原则)

[1. 逻辑必须足够轻量](#1. 逻辑必须足够轻量)

[2. 不要在 runTest() 中做初始化](#2. 不要在 runTest() 中做初始化)

[3. runTest() 必须只做"一个样本"的工作](#3. runTest() 必须只做“一个样本”的工作)

[4. 必须正确返回 SampleResult](#4. 必须正确返回 SampleResult)

[五、Java Request Sampler 的优点](#五、Java Request Sampler 的优点)

[六、Java Request Sampler 的缺点](#六、Java Request Sampler 的缺点)

[七、Java Request vs JSR223 Sampler](#七、Java Request vs JSR223 Sampler)

八、典型使用流程总结

九、总结

[JUnit Request（JUnit 请求采样器）全面解析](#JUnit Request（JUnit 请求采样器）全面解析)

[一. JUnit Request 的作用](#一. JUnit Request 的作用)

[二. JUnit Request 的运行机制](#二. JUnit Request 的运行机制)

[三. 主要配置参数说明](#三. 主要配置参数说明)

基本信息配置

测试类加载与查找方式

测试执行控制

结果消息与状态码配置

错误信息附加选项

[四. 使用 JUnit Request 的典型场景](#四. 使用 JUnit Request 的典型场景)

[五. JUnit Request 的限制](#五. JUnit Request 的限制)

[六. 总结](#六. 总结)

[Debug Sampler（调试采样器）详解](#Debug Sampler（调试采样器）详解)

[一、Debug Sampler 的作用](#一、Debug Sampler 的作用)

[1. 查看 JMeter 变量](#1. 查看 JMeter 变量)

[2. 查看 JMeter 属性](#2. 查看 JMeter 属性)

[3. 查看当前线程组的上下文信息](#3. 查看当前线程组的上下文信息)

[4. 输出测试计划中的执行内容](#4. 输出测试计划中的执行内容)

二、核心配置项说明

[1. Name（名称）](#1. Name（名称）)

[2. Display Variables（显示变量）](#2. Display Variables（显示变量）)

三、典型使用场景

[1. 调试提取器是否正常工作](#1. 调试提取器是否正常工作)

[2. 检查用户自定义变量和函数执行结果](#2. 检查用户自定义变量和函数执行结果)

[3. 排查脚本中的变量覆盖问题](#3. 排查脚本中的变量覆盖问题)

[4. 分析脚本结构执行顺序](#4. 分析脚本结构执行顺序)

四、在监听器中查看输出

五、最佳实践

[OS Process Sampler（操作系统进程采样器）详解](#OS Process Sampler（操作系统进程采样器）详解)

一、核心功能与作用

[1. 执行外部命令或脚本](#1. 执行外部命令或脚本)

[2. 动态生成输入数据或环境准备](#2. 动态生成输入数据或环境准备)

[3. 执行测试后的清理工作](#3. 执行测试后的清理工作)

[4. 结合参数化实现灵活操作](#4. 结合参数化实现灵活操作)

[二、OS Process Sampler 参数说明](#二、OS Process Sampler 参数说明)

[Command to Execute（要执行的命令）](#Command to Execute（要执行的命令）)

[Command Parameters（命令参数）](#Command Parameters（命令参数）)

[Environment Variables（环境变量）](#Environment Variables（环境变量）)

[Standard Streams（标准流配置）](#Standard Streams（标准流配置）)

[Return Code Configuration（返回码配置）](#Return Code Configuration（返回码配置）)

[Timeout Configuration（超时）](#Timeout Configuration（超时）)

三、采样结果中的重要信息

四、典型使用场景概述

五、最佳实践

[JMeter Sampler 全面总结](#JMeter Sampler 全面总结)

在 JMeter 的整个测试执行流程中，采样器（Sampler）是最核心的执行单位------它决定了 JMeter 实际向服务器发送什么请求、以什么协议发送、携带何种数据、如何处理响应，并最终将结果反馈给断言、监听器等组件。

Apache JMeter - User's Manual: Component Reference

如果把 JMeter 看作一个"模拟用户平台"，那么采样器就是"用户的行为动作"。

比如：

  • 访问某个 HTTP 接口

  • 执行一条 SQL 查询

  • 通过 MQTT 或 WebSocket 发送一条消息

  • 下载 FTP 文件

  • 自定义脚本处理等

本节将从概念 → 工作原理 → 常用采样器 → 高级功能 全面解析。

1. 什么是 Sampler？（核心概念）

在 JMeter 中，Sampler 是 用于向服务器发送请求并接收响应 的组件。

它是整个测试脚本的"执行者"，即：

  • 每个 Sampler = 假设一个用户执行一个真实操作

  • Sampler 决定了测试的协议、接口、操作类型

  • Sampler 产生的结果（SampleResult）会被断言、监听器处理和展示

一句话总结：Sampler 是 JMeter 里真正"干活"的东西，负责发请求、收响应、产生日志与测试结果。

2. Sampler 的执行机制（非常重要）

当线程组运行时，每个线程会按顺序执行 Sampler，并为每个 Sampler 生成一个 SampleResult。

Sampler 执行流程如下：

  1. 构造请求（URL、Body、Headers、参数等）

  2. 发送请求 / 执行命令 / 调用协议

  3. 等待响应

  4. 生成 SampleResult，其中包含：

    • 响应码（HTTP Code / 状态码）

    • 响应时间（Elapsed Time）

    • 请求大小 / 响应大小

    • 成功 / 失败标志

    • 响应内容（Body）

  5. 传递给：

    • 断言（Assertions）

    • 后置处理器（Post-Processors）

    • 监听器（Listeners，例如查看结果树、统计报告等）

所有的分析、报告、断言、提取几乎都基于 SampleResult。

3.官方支持的主要 Sampler

取样器类型 Sampler 名称 用途 / 特点
HTTP 类取样器 HTTP Request JMeter 中使用最频繁的取样器，用于向 Web 服务器发送 HTTP/HTTPS 请求。
HTTP 类取样器 GraphQL HTTP Request 用于测试 GraphQL API
HTTP 类取样器 AJP/1.3 Sampler 模拟 AJP 协议请求（Apache JServ Protocol），用于测试连接 Apache HTTP Server + Tomcat 的架构。
HTTP 类取样器 Access Log Sampler 从 Web 服务器 access.log 中读取真实访问记录，自动回放用户访问行为。
文件与传输类取样器 FTP Request 上传/下载 FTP 服务器上的文件。
文件与传输类取样器 TCP Sampler 向服务器发送自定义 TCP 数据包。
消息队列类取样器 JMS Publisher 向 JMS 队列 / Topic 发布消息。
消息队列类取样器 JMS Subscriber 订阅 Topic，接收消息。
消息队列类取样器 JMS Point-to-Point 点对点消息发送/接收，多用于企业系统。
消息队列类取样器 Bolt Request 测试 Bolt（阿里开源 RPC 协议）服务。
邮件类取样器 SMTP Sampler 模拟发送邮件（SMTP）。
邮件类取样器 Mail Reader Sampler 读取邮件（POP3 / IMAP）。
数据库类取样器 JDBC Request 执行 SQL 查询、更新、批处理。
目录服务取样器 LDAP Request 连接 LDAP 服务执行查询。
目录服务取样器 LDAP Extended Request 执行扩展 LDAP 操作（Bind、Rename、Delete 等）。
脚本类取样器 JSR223 Sampler 使用 Groovy/JavaScript/JRuby 编写脚本。
脚本类取样器 BeanShell Sampler 编写 Java 脚本，但性能较差。
脚本类取样器 Java Request 通过编写 Java 类扩展自定义取样器。
脚本类取样器 JUnit Request 执行 JUnit 测试用例，将测试脚本作为 Sampler。
脚本类取样器 Debug Sampler 打印所有 JMeter Variables、Properties、Context 等调试信息。
系统与外部程序执行 OS Process Sampler 在本地计算机上执行操作系统命令或脚本。

4.Sampler详细分析

HTTP Request全面解析

在 JMeter 的所有取样器（Sampler）中，HTTP Request 是使用频率最高、功能最丰富、应用最广泛的组件。对于 Web 服务、REST API、WebSocket 协议等绝大多数性能测试来说，它都是测试脚本的核心。

一. HTTP Request 是什么？

HTTP Request 是 JMeter 中最常用、最核心的采样器之一，用于向服务器发送 HTTP/HTTPS 请求并获取响应。

它支持：

  • 常规 HTTP 请求（GET/POST/PUT/DELETE 等）

  • 文件上传 / multipart 表单

  • 自动抓取页面中的图片、CSS、JS 等嵌入资源

  • GraphQL over HTTP

  • Proxy（代理）转发

  • Keep-Alive

  • Redirect 处理

  • 客户端证书、SSL 配置

  • Cookie、认证、Header 管理

    ... 等几乎所有真实浏览器具备的 HTTP 行为。

二. HTTP Request Sampler 的典型应用场景

场景 示例
Web 页面压力测试 首页、产品页、搜索页等 URL
REST API 性能测试 JSON / XML / protobuf 接口
业务系统压力回放 模拟真实业务流程
微服务网关测压 Nginx、Kong、Apache APISIX、Zuul
文件上传/下载 图片、压缩包、大文件
HTTPS 证书相关测试 双向认证、客户端证书

无论是应用系统、分布式服务还是静态资源，都能通过 HTTP Request 进行测压。

三. HTTP Request 参数详解（最核心部分）

以下按界面结构讲解所有重要配置项。

3.1 Protocol (http / https)

一般情况下不需要填写，除非 URL 中没有指定协议：

  • http

  • https

https 会自动处理 SSL/TLS 握手。

3.2 Method（请求方法）

默认：GET

支持所有标准方法：

方法 用途
GET 查询（URL 参数）
POST 提交、创建
PUT 覆盖更新
PATCH 局部更新
DELETE 删除
HEAD 检查资源是否存在
OPTIONS CORS 检查
3.3 Server Name or IP （域名/IP）

例如：

复制代码 
api.example.com

也可以用变量：

复制代码 
${host}
3.4 Port Number（端口）

默认端口时可以不填：

  • HTTP → 80

  • HTTPS → 443

3.5 Path（路径）

例如：

复制代码 
/api/v1/user/login

支持变量：

复制代码 
/items/${itemId}
3.6 Parameters（请求参数）（适用于 GET、DELETE、POST、PUT）

每个参数可选：

  • URL Encode

  • Include equals (=)

  • 文件上传字段

  • multipart/form-data

参数处理规则：

  • GET / DELETE：追加到 URL

  • POST / PUT：放入请求体（可自动 multipart 或 x-www-form-urlencoded）

用于 GET 或 POST 表单（x-www-form-urlencoded）：

Name Value
username admin
password 123456

支持变量：

Value
${user}
3.7 Body Data（请求体）

当所有参数都没有 name 时，可切换到 Body Data：

适用于：

  • JSON REST API

  • XML REST API

  • SOAP

  • GWT RPC

  • GraphQL（非专用版）

  • 任意自定义文本 Body

每行自动追加 CRLF（最后一行除外）。

用于 JSON、XML、文本请求。

例：

复制代码 
{
  "username": "test",
  "password": "123456"
}

必须搭配：

Headers → Content-Type = application/json

3.8 File Upload（文件上传）

用于 multipart/form-data 请求。

File Path Parameter Name
/tmp/a.png image

四. HTTP Request 工作流程

线程组生成虚拟用户 → Sampler 构造 HTTP 请求 → 发送至服务器 → 接收响应 → 断言校验 → 监听器统计结果

流程：

复制代码 
Thread → PreProcessor → HTTP Sampler → PostProcessor → Assertions → Listener

GraphQL HTTP Request 全面解析

GraphQL 在现代 Web 开发中越来越常见，尤其在前后端分离、微服务架构和移动应用中。为了让性能测试人员更方便地构建 GraphQL 性能测试，JMeter 从 5.6 版本开始新增了 GraphQL HTTP Request，这是对传统 HTTP Sampler 的增强 UI 版本。

一.GraphQL HTTP Request 是什么？

GraphQL HTTP Request 是 JMeter 内置的一种 HTTP Request 的特殊 GUI 变体（Variation）。

底层仍使用：

复制代码 
HTTP Request Sampler (with HttpClient4)

不同之处在于它提供了专门用于 GraphQL 的界面字段：

  • Query（GraphQL 查询字符串）

  • Variables（JSON 变量）

  • Operation Name（操作名称）

这些字段会被 JMeter 自动转换为标准 GraphQL POST/GET 参数格式，不必手写 JSON 请求体。

二.为什么不用普通 HTTP Request？

普通 HTTP Request 可以完成 GraphQL 测试，但你需要：

  • 在 Body Data 写一段 JSON

  • 保证格式正确

  • 处理变量嵌套

  • 手动加入 Content-Type: application/json

  • 注意 JSON 转义

比如 GraphQL 的标准 POST 请求：

复制代码 
{
  "query": "query GetUser($id: ID!) { user(id: $id) { name age }}",
  "variables": {
    "id": "1"
  },
  "operationName": "GetUser"
}

GraphQL HTTP Request 则自动生成，让你：

  • 把 Query 直接贴进去（不需要转义）

  • Variables 用 JSON 输入

  • 自动转换成 HTTP 请求

非常适合大量复杂 GraphQL Query/Mutation 的性能测试。

三.GraphQL HTTP Request 的界面结构

JMeter 的 GraphQL GUI 会隐藏/禁用与 GraphQL 无关的东西：

  • Method 仅支持：GET、POST（符合 GraphQL 规范）

  • Parameters 页面被隐藏

  • File Upload 隐藏

  • Embedded Resources 隐藏（因为 GraphQL 不返回 HTML）

  • Body Data 自动生成，不需手写

界面主要包含：

✔ Query

你的 GraphQL 查询、mutation 或 subscription（注意仅 HTTP 测试，不支持 WS）

例：

复制代码 
query GetUser($id: ID!) {
  user(id: $id) { id name }
}

✔ Variables

JSON 格式变量，例如：

复制代码 
{"id": "1"}

⚠ 注意一定要合法 JSON，否则会在 Log 里报 ERROR 并忽略 Variables。

✔ Operation Name

GraphQL 文档里多个操作时必须填写。

例：

复制代码 
query GetUser { ... }
query GetProduct { ... }

s.JMeter 如何将这些字段拼成实际 HTTP 请求？

示例：

Query:

复制代码 
query GetUser($id: ID!) { user(id: $id) { name } }

Variables:

复制代码 
{"id": "1"}

Operation Name: GetUser

GraphQL HTTP Sampler 会自动生成 POST Body：

复制代码 
{
  "query": "query GetUser($id: ID!) { user(id: $id) { name } }",
  "variables": { "id": "1" },
  "operationName": "GetUser"
}

无需你写任何 JSON。

五.GET 和 POST 的差异

🔹 GET

JMeter 会将 GraphQL JSON 转成 URL 编码参数：

复制代码 
GET /graphql?query=...&variables=...&operationName=...

🔹 POST（默认）

标准 GraphQL HTTP 请求方式，强烈建议使用。

六.GraphQL HTTP Request 参数说明

字段 说明 是否必填
Query GraphQL 查询（或 mutation）语句 ✔ 必填
Variables JSON 格式的变量 可选
Operation Name 多操作文档专用 可选
Method GET / POST（默认 POST） ✔ 必填
其他 HTTP 配置字段 和 HTTP Request 相同 视情况

七. 常见错误与踩坑

❌ Variables 不是合法 JSON

会被忽略并在 Log 出 ERROR。

❌ Query 内含换行、引号未处理

用图形界面不需要转义！直接粘贴即可。

❌ 忘记 Content-Type: application/json

某些 GraphQL 服务器会拒绝请求。

❌ GET 请求 URL 超长

POST 更安全。

八.GraphQL HTTP Request 和 HTTP Request 的关系总结

项目 Gr *** ** * ** *** aphQL HTTP Request 普通 HTTP Request
底层实现 HTTP Request HTTP Request
UI GraphQL 友好界面 通用表单
拼 JSON Body 自动 手动写 Body Data
Method 支持 GET、POST 多种（PUT、DELETE 等）
参数界面 Query / Variables / Operation Parameters 或 Body Data
Embedded Resources 隐藏 可用
File Upload 隐藏 可用

本质：

👉 只是对 HTTP Sampler 的封装，使 GraphQL 请求更好写。

AJP/1.3 Sampler 全面解析

在 JMeter 的全部取样器中，AJP/1.3 Sampler（Apache JServ Protocol） 是一个相对小众但非常重要的组件，主要用于与 支持 AJP 协议的 Web 服务器 （如 Apache HTTP Server + mod_jk / mod_proxy_ajp、Tomcat AJP Connector）进行交互。

如果你的测试场景涉及传统 Java Web 架构（Apache → Tomcat），AJP Sampler 能帮助你绕过 HTTP 层，直接压测后端应用服务，获得更真实、更底层的性能表现。

一.什么是 AJP/1.3？它适用于哪些场景？

AJP（Apache JServ Protocol）是一个 二进制协议，设计用于：

  • Web 前端服务器（Apache、Nginx，通过插件）

  • ⇆ 后端 Servlet 容器（Tomcat、Jetty）

进行高速通信。

常见架构：

复制代码 
Client → Apache（反向代理）→ Tomcat （AJP Connector）

使用 AJP sampler，你可以：

  • 绕过 Apache/Nginx 反向代理层

  • 直连 Tomcat 的 AJP 端口（默认 8009）

  • 测试后端 Java Web 应用的原始性能

如果你的系统采用了 AJP Proxy，这个取样器非常有价值。

⚠️ 注意

许多系统正在逐步弃用 AJP（因安全问题，如 Ghostcat CVE-2020-1938）。

但大量旧系统仍然依赖它，因此 JMeter 仍保留该取样器用于兼容测试。

二. AJP/1.3 Sampler 参数详解

JMeter 为这个取样器提供了一套类似 HTTP Sampler 的界面，只是协议与底层实现不同。

以下是关键参数介绍：

① Server（服务器地址）

填写目标 Tomcat（或其他容器）中启用 AJP Connector 的主机地址。

示例：

  • localhost

  • 10.0.0.15

  • service.internal.company.com

② Port（端口）

默认 AJP 端口为：

复制代码 
8009

如果你的 Tomcat server.xml 中配置了不同端口，请根据实际填写：

复制代码 
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
③ Method（请求方法）

支持与 HTTP 类似的 Method：

  • GET

  • POST

  • PUT

  • DELETE

④ Path（资源路径）

例如：

  • /api/login

  • /hello

  • /user/list

不含域名，只填写 相对路径。

⑤ Parameters（请求参数）

如果 method 是 GET/POST，填写 key-value 参数即可。

⑥ Request Headers

AJP 转发的 header 也可以在这里添加。

例如：

  • Content-Type: application/json

  • Authorization: Bearer ...

支持与 HTTP Sampler 相同的 header 配置形式。

⑦ Message Body（请求体）

用于 POST/PUT 请求，支持 JSON、XML、表单等。

⑧ Timeout（超时）

防止后端卡住导致线程阻塞。

三. AJP Sampler 的优势

优势 说明
🚀 性能高于 HTTP 二进制协议，开销更低
🔍 可直测后端应用 绕过 API Gateway、反向代理等中间层
🧪 更精确的 Java Web 性能测试 对 Servlet/JSP 应用尤为精准
🧩 完全兼容老旧企业架构 许多 legacy 系统仍在使用 AJP

四.AJP 测试注意事项

1. 必须启用 AJP Connector

Tomcat 默认关闭 AJP（新版本）。

确认 server.xml：

复制代码 
<Connector port="8009" protocol="AJP/1.3" secretRequired="false" />

若有 secret 需配置 secret 参数。

2. 可能被防火墙或代理屏蔽

很多生产环境禁止直接访问 8009 端口。

3. 安全风险（Ghostcat）

CVE-2020-1938 导致 AJP 被标记为高危协议。

只建议用于测试，不建议暴露端口。

五.总结

AJP/1.3 Sampler 是 JMeter 中用于测试支持 AJP 协议的 Web 应用服务器的专用取样器，非常适用于传统 Java Web 架构。虽然现代系统逐步迁移到 HTTP/HTTP2，但对于保留 AJP 的企业级系统，它依然具有重要价值。

适用：

  • 老系统迁移前的性能基准

  • 直测 Java Web 容器性能

  • 绕过反向代理后的核心应用测试

如果你的架构中有 AJP，建议一定掌握这个 Sampler。

Access Log Sampler 全面解析

在性能测试中，很多团队已经拥有线上实际的 Web 访问日志（Access Log），其中包含了用户真实访问的 URL、请求参数、资源请求等信息。如果能够直接利用这些日志生成 JMeter 请求，就能让压测更贴近真实业务流量模式，而不是依赖人工编写请求。这正是 Access Log Sampler（访问日志取样器） 的作用。

它是 JMeter 中一个专门用于 从访问日志文件动态生成 HTTP 请求 的取样器，特别适合以下场景：

  • 已有现网 Access Log，想复现真实流量路径

  • 想模拟用户访问行为，但不希望手动维护大量 HTTP 请求

  • 想利用线上日志生成 baseline 性能测试

  • 想支持动态 URL / 参数，而不是固定模板

一. Access Log Sampler 的核心功能

Access Log Sampler 本质上不是"发 HTTP 请求的采样器"，它是一个 日志解析器 + HTTP 请求生成器 的组合。

它的职责是：

模块 作用
日志解析器（Parser） 从 access log 读取 URI，例如 /product/detail?id=123
HTTP Request 构建器 根据你的 Default Test Values（协议、域名、端口）拼接完整请求
请求执行器 发出实际 HTTP 请求

它能自动处理：

  • URL

  • Query 参数

  • 静态资源请求（可选择是否忽略）

  • 日志顺序执行或随机执行

二. 常见适配的日志格式

Access Log Parser 默认支持：

  • Apache HTTPD Access Log

  • Tomcat Access Log

  • Nginx 日志（需使用兼容格式）

  • 自定义格式（通过写 Filter/Parser 扩展）

典型日志格式示例（Apache）：

复制代码 
192.168.1.10 - - [24/Feb/2025:13:55:36 +0800] "GET /item/1234 HTTP/1.1" 200 532

JMeter 能从中自动提取：

  • 请求方法

  • URL

  • Query 参数

  • 协议版本

三. Access Log Sampler 的界面字段说明

以下是其配置项的完整解析（按 UI 布局讲解）：

① Default Test Values（默认请求属性）

这些字段决定生成的 HTTP 请求最终发往哪里：

字段 说明
Protocol http / https，由你指定
Server 你的目标服务器域名或 IP
Port 服务器端口

日志本身通常不包含服务器信息，因此这里必须手动填写，否则生成的请求无法完整拼接。

示例：

  • Protocol: https

  • Server: api.example.com

  • Port: 443

最终可将 /item/1234 转为：

复制代码 
https://api.example.com:443/item/1234
② Parse Images（是否解析静态资源）

默认：False

如果开启，将会处理图片、JS、CSS，例如：

  • GET /images/banner.jpg

  • GET /js/main.js

通常在压测中会关闭，因为静态资源对 CPU/DB 无压力，会污染数据。

③ Parser（日志解析器）

关键配置，用于解析日志行。

默认内置：

  • org.apache.jmeter.protocol.http.util.accesslog.TCLogParser（Tomcat）

  • org.apache.jmeter.protocol.http.util.accesslog.LogParser（通用）

选择解析器时，需要匹配你的日志格式，否则解析失败。

④ Filter（可选过滤器）

控制哪些日志行被执行：

  • 只执行包含某些 URL 的行

  • 排除静态资源

  • 根据业务模块分流访问

例如只压测商品详情页：

复制代码 
/product/*
⑤ Log File（日志文件位置）

你需要指定：

复制代码 
access.log

可支持多种格式：

  • .log

  • .txt

  • 多行大文件

JMeter 会按顺序读取日志（或根据 Parser 逻辑读取）。

四. Access Log Sampler 的执行原理

其内部执行链路如下：

复制代码 
Access Log File  →  Parser  →  URI/Method 提取
        ↓
Default Test Values →  构建 HTTP 请求
        ↓
JMeter HTTPClient → 真实发送请求

这意味着：

  • 日志行中的 method、URI 会被真实执行

  • 响应结果会出现在 Listener 中（View Results Tree 等）

  • 可与其他 Sampler 混搭

五. 使用示例：从 access.log 自动生成流量

假设 access.log 内容：

复制代码 
GET /item/1001 HTTP/1.1
GET /item/1002 HTTP/1.1
GET /cart/add?pid=1001 HTTP/1.1

设置 Default Test Values：

Access Log Sampler 会生成并依次请求：

复制代码 
GET https://shop.example.com/item/1001
GET https://shop.example.com/item/1002
GET https://shop.example.com/cart/add?pid=1001

完全自动化，无需单独添加 HTTP Sampler。

六. 适用场景

✔ 非常适用：

  • 重放真实 Web 流量

  • 从生产日志生成测试用例

  • 快速搭建性能测试基线

  • 连续压测，模拟真实用户行为链路

✘ 不适合：

  • 分布式 API 调用（非 Web）

  • 需要复杂动态参数的场景

  • 需要控制业务逻辑（推荐使用 JSR223）

七. 总结

Access Log Sampler 是典型的"低门槛高价值"组件。只需导入访问日志，就能立即构建一套贴近真实用户行为的性能测试模型，极大地提升压测的真实性与效率。

适合作为：

  • 电商

  • 门户网站

  • Web 系统

  • 负载均衡真实流量回放

的快速压测方案。

FTP Request Sampler 全面解析

FTP（File Transfer Protocol）依旧广泛用于企业内部的数据同步、日志传输、文件备份等场景。许多系统的后台任务、ETL 数据管道、设备上传数据等都依赖 FTP 服务。因此，在性能测试中模拟 FTP 上传／下载行为非常常见。

JMeter 提供了专门的 FTP Request Sampler，用于模拟 FTP 客户端上传、下载文件，以测试 FTP 服务器的吞吐能力、并发性能与稳定性。

一. FTP Sampler 的作用

FTP Request Sampler 允许 JMeter 执行：

  • 文件下载（RETR）

  • 文件上传（STOR）

  • 目录访问

  • 文件操作（部分 FTP 命令）

主要用于：

  • 测试 FTP 服务器的并发处理能力

  • 压测大文件传输性能（如 50MB、500MB、1GB...）

  • 模拟大量客户端同时上传/下载文件

  • 验证 FTP 服务的稳定性与吞吐量

对于需要测试大文件读写性能的系统（如 BI 系统、日志服务器、企业数据交换平台），非常有价值。

二. FTP Request Sampler 参数详解

① Server Settings（服务器配置）
参数 描述
Server Name or IP FTP 服务器的主机名或 IP
Port Number 默认 21，FTP 常用端口

示例：

复制代码 
ftp.mycompany.com
21
② File to Retrieve or Upload（操作文件）

决定取样器执行上传还是下载。

参数 含义
Remote File FTP 服务器上的文件路径（下载）
Local File 本地待上传文件路径

行为规则如下：

✔ 如果 Local File 为空 → 执行文件下载（RETR）

示例：

复制代码 
Remote File: /data/report.csv
Local File: (空)

表示下载 /data/report.csv。

✔ 如果 Local File 不为空 → 执行文件上传（STOR）

示例：

复制代码 
Local File: D:/upload/test.jpg
Remote File: /upload/test.jpg

表示上传本地文件到服务器指定目录。

③ Use Binary Mode？（是否二进制模式）

默认：勾选（TRUE）

二进制模式适合几乎所有类型文件（图片、视频、压缩包等）。

如果取消勾选，使用 ASCII 模式，但通常不推荐。

④ Login Configuration（登录设置）

FTP 大多需要用户名密码。

参数 描述
Username FTP 账号
Password FTP 密码

如果是匿名 FTP：

复制代码 
Username: anonymous
Password: yourEmail@example.com
⑤ Other Options（其他选项）
  1. Local File Contents

直接在取样器内部填写要上传的内容，而不需要依赖本地实际存在的文件。

  1. Save File in Response ?

可将 FTP 响应保存到 Listener 中，便于调试。

三. 典型应用场景

✔ 1. 压测企业文件交换平台

内部系统依赖 FTP 同步数据，使用 JMeter 模拟大量员工上传报表。

✔ 2. 测试 ETL 数据文件传输性能

如每天机器会上传大量日志到 FTP 服务器。

✔ 3. 测试 CDN/镜像源的文件下载能力

用于监测高并发下载时的吞吐量与稳定性。

✔ 4. 模拟 IoT/边缘设备上传数据文件

IoT 设备批量上传：

  • sensor.log

  • camera.jpg

  • zip 包

可用 JMeter 批量模拟关键路径。

四. 使用 FTP Sampler 的常见问题

❗ 1. 上传文件失败

可能原因：

  • FTP 用户权限不足

  • 上传目录不存在

  • 被被动模式/主动模式影响（JMeter 使用普通 FTPClient）

❗ 2. 下载文件为 0 字节

可能原因：

  • Remote File 配置错误

  • FTP 用户无读取权限

  • ASCII 模式损坏内容（请使用 Binary Mode）

❗ 3. 大文件上传异常慢

原因可能包括：

  • FTP 服务器从单线程到磁盘 IO 冲突

  • 网络带宽不足

  • 多线程导致服务器拒绝连接数

解决方案：

  • 调整 Thread Group 的并发量

  • 设置 Think Time

  • 使用 FTP 服务端的并发优化配置

五. 总结

FTP Request Sampler 是 JMeter 中经典但非常实用的取样器之一，适合需要模拟文件传输行为的各种性能测试场景。它支持：

  • 文件上传

  • 文件下载

  • 并发传输

  • 大文件吞吐压测

对于企业内部系统、数据管道、物联网设备接入等场景极其重要。

TCP Sampler 全面解析

除了 HTTP、JDBC 等常见协议外，JMeter 还支持更底层、更通用的网络协议测试------TCP。对于需要模拟自定义协议、内部服务通信、设备对接、socket server 性能测试的场景，TCP Sampler 是非常重要的工具。

它不依赖 HTTP，不依赖 REST，不依赖任何框架，而是直接通过 TCP Socket 与目标服务通信。对于 IoT、游戏服务器、金融报文、定制二进制协议系统，这非常关键。

一. TCP Sampler 是什么？

TCP Sampler 是 JMeter 提供的基础取样器，用于：

  • 直接创建 TCP 连接

  • 向服务器发送字节数据

  • 接收服务器返回结果

  • 按线程模型模拟大量 Socket 客户端

换句话说：

TCP Sampler 就是一个"可编程的 Socket 客户端"，用于测试原始 TCP 协议服务器的性能与响应。

支持 ASCII 文本、十六进制、二进制数据。

二. 典型应用场景

TCP Sampler 的使用范围非常广泛，尤其适用于非 HTTP 的系统：

✔ 1. 测试自定义协议服务

许多内部系统采用自定义的报文格式，例如：

  • 金融机构的自定义报文协议

  • 企业网关的内部二进制协议

  • 游戏服务器的自定义 socket 通信

  • 消息队列的自定义 TCP 传输模式

✔ 2. IoT 设备模拟

大量设备通过 TCP 上传数据：

  • GPS 报文

  • 传感器上报数据

  • 工控设备的数据帧

TCP Sampler 可以轻松模拟成千上万的设备。

✔ 3. 测试内网微服务网关

某些内部架构中：

  • HTTP → API 网关

  • TCP → 深层内部服务

用于性能测试底层组件的并发能力。

✔ 4. 测试 Socket Server 稳定性

例如 Node.js、Java NIO、Netty、C++ 服务端。

三. TCP Sampler 参数详解

① Server Name or IP

目标 TCP 服务地址，如：

复制代码 
192.168.10.15
iot.server.local

② Port Number

TCP 服务监听的端口，如：

复制代码 
9000
1883（MQTT）
502（Modbus）
8088

③ Re-use connection（重用连接）

是否复用同一个 TCP Socket。

  • ✔ 勾选：长连接模式（更接近真实场景）

  • ✘ 不勾选：每次采样创建新连接

很多自定义协议都依赖长连接，因此通常勾选。

④ Close connection（关闭连接）

每次采样后是否关闭 TCP 连接。

一般以下情况勾选：

  • 协议本身需要短连接

  • 服务端对连接敏感，要求断开

若与"Re-use connection"冲突，以 Close 为优先。

⑤ SO_LINGER

Socket linger 参数，一般保持默认即可。

⑥ End of line(EOL) byte value

用于指定换行符，以便 JMeter 识别返回内容结束。

常见：

  • 10（LF, \n）

  • 13（CR, \r）

  • 13,10（CRLF, \r\n）

如果是文本协议如 Telnet 风格，通常服务器以 \r\n 结束。

⑦ Request Data（发送的数据）

这是最重要的部分。

你可以填写要发往服务器的内容，例如：

复制代码 
GET_STATUS

也可以使用 JMeter 函数：

复制代码 
id=${__Random(1,9999)}
report=${id},${__time()}

⑧ Text Mode / Hex Mode

TCP Sampler 支持两种发送模式：

✔ Text Mode（默认）

按普通字符串发送：

复制代码 
HELLO
12345,89,OK
JSON...
XML...

适用于 ASCII 协议。

✔ Hex Mode

用于发送十六进制（二进制）报文：

复制代码 
48 65 6C 6C 6F 20 57 6F 72 6C 64

对应文本为 "Hello World"。

适用于二进制协议、定长报文协议。

四. 典型使用示例

示例 1：文本协议服务

请求：

复制代码 
LOGIN|user001|pass123

响应：

复制代码 
OK

非常常见的内部系统格式。

示例 2：JSON over TCP

复制代码 
{"device":"A103","signal":82,"timestamp":${__time()}}

示例 3：二进制协议（Hex Mode）

报文：

复制代码 
01 10 00 01 00 02 04 00 0A 00 14

适用于 Modbus / 定制二进制协议。

五. 返回结果解析（Response）

响应结果显示在 Listener → View Results Tree 中，包含：

  • 请求内容

  • 服务端返回内容

  • 往返时间（RTT）

  • 连接耗时

  • Raw 二进制内容（如果是 Hex 模式）

六. 使用 TCP Sampler 的常见注意事项

❗ 1. 如果服务端没有返回结束标志，TCP Sampler 会卡住

必须设置：

  • End of line (EOL)

  • 或者使用 TCPClientClass

❗ 2. 许多协议需要固定格式报文

例如：长度字段 + 内容字段

此时必须使用 PreProcessor + JSR223 动态生成报文。

❗ 3. 并发高时服务器可能因连接数限制崩溃

建议测试前检查：

  • ulimit -n

  • 服务端最大连接数

  • 最大线程池数

❗ 4. 不适用于 SSL/TLS 加密的 TCP（如 TLS Socket）

那属于：

  • JMS

  • MQTT over TLS

  • 自定义 SSL socket

TCP Sampler 无法直接处理 SSL。

七. 进阶：使用 TCPClientClass 扩展协议

JMeter 允许你自定义 Java 类解析 TCP 数据，例如：

复制代码 
org.apache.jmeter.protocol.tcp.sampler.BinaryTCPClientImpl

你可以：

  • 添加报文头

  • 解析二进制结构体

  • 处理复杂协议

非常强大。

八. 总结

TCP Sampler 是 JMeter 中最灵活、最底层的取样器之一，可以直接模拟 TCP 客户端，适用于：

  • 自定义协议

  • 二进制协议

  • 游戏服务器

  • IoT 设备

  • 金融报文

  • 内网网关

它支持文本与 Hex 模式，支持长短连接，并可以通过自定义 Java 类进行扩展，是测试 socket server 并发性能的重要工具。

Publisher Sampler 全面解析

在现代企业系统中，消息中间件（MQ）被广泛应用于异步通信、削峰填谷、业务解耦等核心场景。而在性能测试中，我们不仅需要压测 HTTP，还要验证 JMS（Java Message Service） 系统的吞吐能力、消息延迟与稳定性。

JMeter 提供了三个用于 JMS 的取样器：

  • JMS Publisher -- 发布消息到 Topic/Queue

  • JMS Subscriber -- 订阅者（用于接收）

  • JMS Point-to-Point -- 点对点消息发送与接收

一. JMS Publisher 是什么？

JMS Publisher Sampler 是 JMeter 提供的一个"消息发布"取样器，用于向消息中间件发送 JMS 消息。它支持：

  • Queue（点对点）

  • Topic（发布订阅）

  • 文本消息、Map 消息、Object 消息

  • 自定义消息属性

  • 随机消息内容模拟真实压力

适用于所有支持 JMS 规范的 MQ，如：

  • ActiveMQ / ActiveMQ Artemis

  • IBM MQ

  • HornetQ

  • TIBCO EMS

  • JBoss Messaging

  • WebLogic JMS

  • RocketMQ（需 JMS 封装）

二. JMS Publisher 的典型应用场景

你可以在以下场景中使用它：

  • 压测消息队列的吞吐量（TPS）

  • 测试 MQ Broker 的稳定性

  • 模拟大量 IoT/业务事件流

  • 验证消费者集群的消费能力

  • 模拟真实系统中大量生产者的行为

如果你的服务是"消费消息的后端服务"，那么 JMS Publisher 就是最适合模拟生产者的工具。

三. JMS Publisher 配置项详解

以下将按界面顺序逐项解释每个配置项的作用与使用方式。

3.1 基础设置
字段 说明
Name 自定义名称
Comments 注释，可填写 MQ 名称、队列名等
3.2 JMS 配置区

✔ Initial Context Factory

JNDI 初始化工厂类，用于创建 JMS 连接。

例如：

  • ActiveMQ

    复制代码 
    org.apache.activemq.jndi.ActiveMQInitialContextFactory

  • IBM MQ

    复制代码 
    com.sun.jndi.fscontext.RefFSContextFactory

✔ Provider URL

JNDI 服务地址（通常是 MQ 服务器地址）。

示例：

复制代码 
tcp://localhost:61616

✔ Connection Factory

用于创建 JMS 连接的工厂类名称。

示例：

复制代码 
ConnectionFactory
TopicConnectionFactory
QueueConnectionFactory

由 MQ 管理员提供或查看 JNDI 配置。

3.3 Messaging 目标配置

✔ Destination

消息发送目标的 JNDI 名称。

示例：

复制代码 
dynamicQueues/myQueue
dynamicTopics/myTopic

注意：ActiveMQ 使用 dynamic 前缀自动创建队列/主题。

3.4 Message 内容配置

✔ Message Type（消息类型）

支持三种：

类型 用途 示例
TextMessage 文本消息（JSON、XML、普通文本） {"id":1,"event":"login"}
MapMessage 键值对结构消息 key=value
ObjectMessage Java 对象序列化传输 自定义对象

最常见也是最推荐的是 TextMessage。

✔ Text Message Content

填写实际发送的内容，例如：

复制代码 
{"event":"userLogin","timestamp":${__time()}}

也可以通过 JMeter 变量动态生成内容：

复制代码 
order-${__Random(1,100000)}

✔ MapMessage / ObjectMessage

如果选择 MapMessage，你需要填写：

  • Key

  • Value

  • 类型（int、string、bool）

适合一些老的企业系统。

3.5 JMS Headers 和 Properties

✔ Request Headers

例如：

复制代码 
JMSType: notification
JMSCorrelationID: abc-123

✔ Message Properties（消息属性）

你可以添加自定义属性：

Key Value 类型
eventType login String
region 1001 int

消费者可以根据属性进行过滤（JMS Selectors）。

3.6 可选项

✔ Use Non-Persistent Delivery

消息不持久化

适合高吞吐场景。

✔ Use Request-Reply

发布后等待响应

适合 RPC-style 的 JMS 系统。

四. 使用示例：发布 JSON 消息到 ActiveMQ

一个最常用的配置如下：

配置项 值
Initial Context Factory org.apache.activemq.jndi.ActiveMQInitialContextFactory
Provider URL tcp://localhost:61616
Connection Factory ConnectionFactory
Destination dynamicQueues/testQueue
Message Type TextMessage
Message Content {"id":"${__UUID}","event":"login"}

执行脚本即可向 testQueue 队列持续发送消息。

五. 性能测试最佳实践

✔ 1. 使用 Non-Persistent 模式提升吞吐量

避免落盘延迟。

✔ 2. 多线程分布式并发

JMS 发布非常依赖网络 I/O，多机器并发能显著提升压力。

✔ 3. 避免开启 Transaction

事务操作会降低性能。

✔ 4. 使用长连接（Connection pooling）

减少连接创建开销。

✔ 5. 配合 Subscriber 进行端到端延迟测试

用于测量"生产 → 消费"的业务链路耗时。

六. 总结

JMS Publisher 是 JMeter 中极为重要的消息队列取样器，适用于：

  • MQ 生产者性能压测

  • 大规模消息流模拟

  • 企业系统异步链路测试

  • 点对点 / 发布订阅双方性能验证

它支持多种 MQ，实现方式标准且灵活，并且通过 JNDI 配置可无缝对接任何 JMS 框架。

Bolt Request 使用详解：Neo4j 数据库性能测试指南

Neo4j 是图数据库领域的核心产品，而 JMeter 在 5.4.1 开始加入 Bolt Request Sampler，支持通过 Neo4j 的 Bolt 协议执行 Cypher 查询，从而对图数据库进行性能评估。

一. Bolt Request 是什么？

Bolt Request Sampler 用于：

  • 通过 Bolt 协议 与 Neo4j 服务器通信

  • 执行 Cypher 查询（读查询、写查询）

  • 提供查询参数、数据库选择、超时设置等

  • 支持记录查询执行结果

这是进行 Neo4j 性能测试最官方、最稳定的方式。

二. 采样器界面总览

界面主要分成 4 大块：

  1. 基本信息

    • Name / Comments

  2. Query 部分

    • Cypher Statement

    • Params

  3. Record Query Results

    • 是否记录 Neo4j 返回的节点/关系 JSON

  4. Options（连接选项）

    • Access Mode

    • Database

    • Transaction timeout

三. 参数详解

以下按界面顺序详细解释每一项设置。

3.1 Name / Comments

  • Name：采样器名称

  • Comments：备注信息

无实际影响，仅用于脚本管理。

3.2 Cypher Statement（Cypher 语句）

这是测试中最重要的部分。

示例 1：读取节点

复制代码 
MATCH (n:User {id: $userId}) RETURN n

示例 2：写入关系

复制代码 
MATCH (a:User {id:$a}), (b:User {id:$b})
CREATE (a)-[:FRIEND]->(b)

Cypher 语句支持变量绑定，通过下方 Params 提供参数。

3.3 Params（查询参数，JSON 格式）

用于填充 Cypher 中的 $参数名。

例如：

复制代码 
{"userId": 1001}

或多个参数：

复制代码 
{
  "a": "u001",
  "b": "u002"
}

如果 Params 与 Cypher 不匹配，会导致 Neo4j 抛出参数错误。

3.4 Record Query Results

  • True：将 Neo4j 返回的数据写入 SampleResult

  • False：仅记录结果摘要（默认）

性能压测时通常关闭，避免存储大量 JSON 导致内存压力。

四. Options 详解

Bolt Request 中的 Options 决定如何连接 Neo4j。

4.1 Access Mode（访问模式）

可选：

  • WRITE → 执行写事务

  • READ → 执行只读查询

  • DEFAULT → 自动模式（Neo4j 自行判断）

如果你在 Cypher 中创建/更新数据，必须使用 WRITE。

4.2 Database（目标数据库）

Neo4j 4.x+ 支持多数据库系统，可在此选择数据库，例如：

  • neo4j

  • system

  • mydb

如果不填，则使用默认数据库（通常为 neo4j）。

4.3 Transaction timeout（事务超时）

单位：秒

默认：60

例如：

  • 查询复杂图结构时可设置更大，如 120 秒

  • 高负载压测时可调小，例如 5 秒

五. 常见错误与排查方法

错误信息 原因 解决方案
Parameter missing Cypher 中有 $id，但 Params 中没写 检查 Params JSON
Database not found 填写了不存在的数据库 使用 SHOW DATABASES 确认
Write operation in READ mode 写入操作却使用 READ 模式 Access Mode 改为 WRITE
Bolt connection refused Neo4j 未开启 Bolt 编辑 neo4j.conf 启用 bolt

六. 总结

Bolt Request 让 JMeter 可以直接连接 Neo4j，实现：

  • 读写性能压测

  • 查询时延分析

  • 图数据库节点、关系操作测试

  • 高并发访问模拟

其配置简单，功能完整，非常适合数据库性能分析、图算法评估与线上容量规划测试。

SMTP Sampler 全面指南：从邮件发送到安全认证

在实际系统中，用户注册、验证码发送、系统告警、报告通知等都依赖邮件服务。因此，测试邮件发送性能与可靠性就成为性能压测必不可少的一环。

JMeter 提供了原生的 SMTP Sampler，用于模拟邮件发送行为，并收集响应时间、错误信息等指标。

一. 基本信息区

Name / Comments

  • Name：采样器名称

  • Comments：可写邮件用途、目标 SMTP 服务器信息等，方便后续维护

二. Server settings（服务器配置）

这一部分决定邮件要发送到哪个 SMTP 服务。

Server

填写邮件服务器地址，例如：

复制代码 
smtp.gmail.com
smtp.office365.com
mail.example.com
192.168.1.20

Port

常用端口：

场景 端口
普通 SMTP 25
SSL SMTP 465
StartTLS 587

默认端口会根据你是否开启 SSL / StartTLS 自动匹配，无需刻意填写。

Timeouts（毫秒）

Connection timeout（连接超时）

SMTP 服务器连接耗时过长会导致此处报错。

一般设置：

复制代码 
30000

Read timeout（读取超时）

用于接收 SMTP server 返回数据超时时间，建议：

复制代码 
30000

三. Mail settings（邮件地址设置）

Address From（发件人）

例如：

复制代码 
noreply@example.com

Address To（收件人）

多收件人用换行分隔：

复制代码 
user1@example.com
user2@example.com

Address To CC（抄送）

Address To BCC（密送）

除了隐私控制以外，BCC 常用于系统日志邮件。

Address Reply-To

收件人点击"回复"时会写入此邮件地址。

四. Auth settings（SMTP 登录认证）

默认 SMTP 服务需要账号密码。

Use Auth（启用认证）

开启后出现：

  • Username

  • Password

登录 Gmail / Outlook / 企业邮件等需要注意：

⚠️ 部分邮箱需要 应用专用密码

⚠️ 部分邮件服务器需要开启 SMTP 服务权限

五. Security settings（安全设置）

JMeter 提供三种模式：

① Use no security features（无加密）

适用于：

  • 内网 SMTP

  • 自建无加密邮件服务

② Use SSL（使用 SSL 加密）

典型端口：465

用于老式 SMTPS 或内部服务器

③ Use StartTLS（最推荐）

StartTLS = 明文连接后升级为 TLS 加密

典型端口：587

Gmail、Outlook、多数云邮件服务推荐使用

Trust all certificates（信任所有证书）

用于测试环境 SSL 证书不规范时。

Local truststore / Override System SSL/TLS Protocols

适用于严格安全环境：

  • 提供特定 truststore

  • 指定加密协议，例如：TLSv1.2

六. Message settings（邮件内容配置）

Subject（标题）

邮件标题，例如：

复制代码 
系统告警：CPU 使用率过高

Include timestamp in subject（标题中加时间戳）

输出示例：

复制代码 
系统告警：CPU 使用率过高 - 2025-01-13 10:24:33

用于区分邮件。

Suppress Subject Header

如果你想完全自定义 MIME Header，可开启此选项。

Add Header

可添加额外 Header，比如：

  • Content-Type

  • X-Priority

  • X-Mailer

示例：

名称 值
X-Priority 1
X-Mailer JMeter-Mailer

Message（邮件正文）

支持：

  • 文本内容

  • HTML 内容

示例（HTML）：

复制代码 
<h3>系统告警</h3>
<p>订单服务超时超过 3 秒，请检查。</p>

Send plain body（非 multipart/mixed）

只发送纯文本，不带附件或复杂 MIME 结构。

七. Attach file(s)（附件设置）

添加附件

多个附件需要：

  • 使用"Browse..."逐个选择

  • 或手动写路径，换行区分

示例：

复制代码 
C:\reports\result.csv
C:\logs\error.log

Send .eml（直接发送 EML 文件）

如果你已有完整邮件内容（含 MIME 和 header），可以直接发送 .eml 邮件文件，非常适合：

  • 再现真实系统邮件

  • 压测时保持内容一致性

八. Additional settings（高级附加项）

Calculate message size

在日志中输出邮件大小。

用于分析邮件体积与性能关系。

Enable debug logging

建议仅用于调试阶段，会显示完整 SMTP 流程：

示例日志：

复制代码 
220 smtp.example.com ESMTP
250 OK
354 End data with <CR><LF>.<CR><LF>
250 Message accepted for delivery

压测时不要开启（影响性能）。

九. 常见错误排查

错误 原因 解决方案
535 Authentication failed 账号/密码错误 使用应用专用密码
530 Must issue STARTTLS first 服务器要求 StartTLS 开启 StartTLS
421 Connection timeout 防火墙阻断 开放端口 587/465
Message rejected 附件太大 / 内容不合法 调整内容或检查策略

十. 总结

SMTP Sampler 不仅可以模拟邮件发送，还支持：

  • HTML 邮件

  • 多附件

  • SSL/StartTLS 安全加密

  • BCC/CC 类企业邮件场景

  • EML 文件发送

  • 自定义 Header

是测试系统邮件模块与 SMTP 服务器最可靠的压测工具。

Mail Reader Sampler（邮件读取采样器）

Mail Reader Sampler 是 JMeter 自带的邮件协议采样器，用于通过 POP3 / IMAP / POP3S / IMAPS 等协议从邮件服务器读取邮件。

它常用于：

  • 自动化验证邮件验证码、通知邮件

  • 邮箱系统可用性监控

  • 邮件读取性能测试

  • 自动读取最新邮件并提取正文

一、Mail Reader Sampler 的用途概览

Mail Reader Sampler 适合以下典型场景：

✔ 场景 1：测试注册/登录验证码邮件

自动读取 INBOX → 解析验证码 → 用于后续接口测试

✔ 场景 2：自动化测试系统邮件

例如：

  • 订单创建后的邮件

  • 预警邮件

  • 审批通知邮件

✔ 场景 3：邮件服务器性能测试

模拟多线程并发读取邮件

✔ 场景 4：企业邮箱可用性监控

每 X 分钟检查 IMAP 是否可用

二、界面字段详解

1. 基础信息

Name

采样器名称，默认 Mail Reader Sampler，可自定义。

Comments

补充备注，可写业务流程描述，例如：

复制代码 
读取注册验证码邮件
2. 协议与连接配置

Protocol (e.g. pop3, imaps)

填写要使用的协议：

协议 常用端口 说明
pop3 110 无加密 POP3
imap 143 无加密 IMAP
pop3s 995 POP3 over SSL
imaps 993 IMAP over SSL（最安全，推荐）

示例：

复制代码 
imaps

Server Host

邮件服务器地址，例如：

  • imap.gmail.com

  • pop.qq.com

  • mail.company.com

Server Port（optional）

不填使用默认端口。

如需要指定，POP3 995 / IMAP 993 常见。

Username

邮箱账号，例如：

  • qa@company.com

  • test@qq.com

Password

邮箱密码或"客户端授权码"。

注意：

Gmail / Outlook / QQ 邮箱均需要授权码，不支持普通密码。

Folder

针对 IMAP 有效，指定读取文件夹：

  • INBOX（默认）

  • Spam

  • Notifications

POP3 固定只能读 INBOX。

3. 邮件读取数量与行为控制

Number of messages to retrieve

两种方式：

All 全部邮件

读取整个邮箱的所有（一页或全部）邮件。

指定数量（建议）

填写数字，例如：

复制代码 
1

表示只读取最新的一封邮件。

性能测试、验证码提取，推荐设置 1。

Fetch headers only

只读取邮件头（From、Subject、Date），不读取正文。

主要用于性能测试或监控场景。

Delete messages from the server

读取后删除邮件。

⚠ 危险！慎用

用于 POP3 模拟"收到后删除"的客户端行为。

不适合用在生产监控或自动化测试中。

Store the message using MIME (raw)

是否把完整 MIME 原文存储下来。

适合邮件解析类测试。

4. 安全设置（SSL / TLS）

新版 UI 在「Security settings」部分提供三选一：

Use no security features（默认）

无加密连接。

仅适用于内部 POP3/IMAP 测试环境。

Use SSL

启用 SSL（通常等于 POP3S / IMAPS）。

如果你填写的协议是 imaps/pop3s，也必须保证这里配置匹配。

Use StartTLS

用于某些服务器（如部分企业 IMAP 服务）：

  • 先建立普通连接

  • 再升级为 TLS

Trust all certificates

如果开启 SSL / StartTLS，勾选此项可忽略证书问题。

适合自签名证书的企业环境。

Use local truststore

需要指定 truststore（.jks）文件，用于校验证书。

Local truststore

填写 .jks 文件路径。

Override System SSL/TLS Protocols

指定协议版本，例如：

复制代码 
TLSv1.2

三、常见问题 FAQ

✔ Gmail 登录失败

必须使用 应用专用密码（App Password）。

✔ 显示 SSL handshake failed

勾选：

复制代码 
Trust all certificates

✔ 读取太慢

优化建议：

  • Number of messages = 1

  • 使用 IMAP 而不是 POP3

  • 不要读取全部邮件

四、总结

Mail Reader Sampler 是邮件系统自动化与压测中非常重要的采样器。

新版 UI 功能更清晰，支持：

  • POP3 / IMAP 多协议

  • 安全连接 SSL / TLS / StartTLS

  • 读取最新邮件并解析

  • 邮箱服务健康监控

  • 完整 MIME 原文保存

适用于多种业务验证场景。

JDBC Request（数据库请求采样器）全面解析

在进行接口、后台业务逻辑或数据库性能测试时，我们经常需要直接对数据库执行 SQL 查询、更新、插入或删除操作。

JMeter 提供的 JDBC Request 正是用于此类测试的核心采样器。

一、JDBC Request 用途概览

JDBC Request 主要用于以下场景：

✔ 1. 测试 SQL 性能

例如：

  • 查询语句耗时

  • 多线程并发执行 UPDATE/INSERT 的压力测试

  • 数据库连接池容量验证

✔ 2. 接口测试的前置/后置数据准备

  • 创建测试数据

  • 核对接口执行后的数据库变化

  • 清理脏数据

✔ 3. 自动化测试

  • 查询验证码

  • 查询订单状态

  • 校验业务逻辑结果

✔ 4. 数据库监控脚本编写

  • 每分钟走一条 SQL，检查数据库健康情况

二、环境前置：JDBC 驱动配置（非常重要）

JDBC Request 要正常工作，必须先配置数据库驱动。

步骤如下：

1. 下载 JDBC Driver

不同数据库需要不同驱动：

数据库 驱动文件
MySQL mysql-connector-j-x.x.x.jar
PostgreSQL postgresql-x.x.x.jar
Oracle ojdbc8.jar
SQL Server mssql-jdbc-x.x.x.jar
2. 将驱动放入 JMeter 的 lib 目录

路径如下：

复制代码 
JMETER_HOME/lib/

放进去后必须 重启 JMeter。

三、JDBC Connection Configuration（数据库连接配置）

在使用 JDBC Request 前，需要添加：

复制代码 
Test Plan → Add → Config Element → JDBC Connection Configuration

关键参数如下：

1. Variable Name（变量名）

例如：

复制代码 
mydb

JDBC Request 将通过它获取连接。

2. Database URL

例如 MySQL：

复制代码 
jdbc:mysql://127.0.0.1:3306/test?useSSL=false&serverTimezone=UTC

PostgreSQL：

复制代码 
jdbc:postgresql://127.0.0.1:5432/test
3. JDBC Driver class

例如：

复制代码 
com.mysql.cj.jdbc.Driver
4. Username / Password

数据库登录账号密码。

5. Max Number of Connections

数据库连接池最大连接数。

四、JDBC Request 采样器界面详解

添加路径：

复制代码 
Thread Group → Add → Sampler → JDBC Request

以下是主要字段解析。

1. Name / Comments

采样器名称与备注，无需解释。

2. Variable Name for created pool（连接池名称）

必须与 JDBC Connection Configuration 中的 Variable Name 一致：

例如：

复制代码 
mydb

不一致会导致无法连接数据库。

3. Query Type（查询类型）

JMeter 提供以下常用类型：

类型 说明
Select Statement 执行 SELECT 语句
Update Statement 执行 INSERT / UPDATE / DELETE
Callable Statement 调用存储过程
Prepared Select Statement 带参数的 SELECT
Prepared Update Statement 带参数的 UPDATE
Commit / Rollback 事务提交或回滚
Close Connection 关闭连接
AutoCommit 设置自动提交

最常用的是：

  • Select Statement

  • Update Statement

  • Prepared Select Statement

  • Prepared Update Statement

4. SQL Query（SQL 语句）

如果是普通查询：

复制代码 
SELECT * FROM users WHERE id=1;

更新：

复制代码 
UPDATE users SET status='OK' WHERE id=1;
5. Parameter values（SQL 参数值）

如果 Query Type 是 Prepared Statement，需要使用：

示例：

复制代码 
1001,OK
6. Parameter types（参数类型）

对应 Java 类型，例如：

复制代码 
INTEGER,VARCHAR
7. Result variable name（结果变量名）

如果填写：

复制代码 
userInfo

查询结果会被存储到 ${userInfo} 中。

例如：

复制代码 
${userInfo_1_id}
${userInfo_1_name}

非常适合验证码查询等自动化测试。

8. Query timeout（超时）

单位秒，默认 0（不超时）。

五、最佳实践与性能优化

1. 尽量复用连接池（不要每个线程重建）

连接创建非常耗时。

2. 使用 Prepared Statement 提升性能

3. 并发测试时注意数据库连接数限制

4. 避免一次返回大量数据（分页查询）

5. 如果做压力测试，建议将 SQL 放到 Stored Procedure 中提升效率

六、常见问题 FAQ

❌ 无法加载驱动

报错：

复制代码 
Cannot load JDBC driver class

解决：把 jar 放到 /lib/ 并重启 JMeter。

❌ Too many connections

数据库连接池过小 → 增大 Max Connections。

❌ SQL 超时

检查索引、网络、锁等待。

七、总结

JDBC Request 采样器是 JMeter 中最灵活、用途最广的采样器之一。

它能够完成：

  • SQL 查询性能测试

  • 并发数据库压测

  • 自动化流程中的数据验证与准备

  • 存储过程压力测试

  • 后台系统联动逻辑验证

LDAP Request

LDAP Request 是 JMeter 内置的轻量级 LDAP 目录性能测试工具，可用于对 LDAP 服务器进行基础的认证、搜索、添加、修改与删除测试。你提供的界面属于 旧版 LDAP Request（非 LDAP Extended）。

界面主要分为两个大部分：

  • Login Configuration（登录配置）

  • Test Configuration（测试配置）

下文逐项说明。

一、Login Configuration（登录配置）

用于配置 LDAP 连接与身份验证信息。所有测试操作均基于此配置建立连接。

1. Username

用于绑定（Bind）LDAP 的登录用户名。

可能的格式：

目录类型 示例
OpenLDAP cn=admin,dc=example,dc=com
Active Directory user@company.com 或 CN=John Smith,CN=Users,DC=company,DC=com

2. Password

用户密码，用于 LDAP 绑定认证。若密码错误，LDAP 通常返回错误码 49（Invalid Credentials）。

3. Servername

LDAP 服务器主机名或 IP，如：

复制代码 
ldap.company.com
192.168.1.10

4. Port

LDAP 端口号：

协议 端口
LDAP（明文） 389
LDAPS（SSL 加密） 636

若使用 SSL，需要在 JMeter 启动参数中配置 TrustStore。

5. DN（Base DN / Root DN）

该字段在旧版 LDAP Request 中用作：

  • 登录时初始的 Base DN

  • Add / Search / Delete / Modify 的默认起始 DN

示例：

复制代码 
dc=company,dc=com
ou=users,dc=company,dc=com

二、Test Configuration（测试配置）

用于选择具体的操作类型。旧版 LDAP Request 支持：

  • Add Test

  • Delete Test

  • Search Test

  • Modify Test

测试行为逻辑说明

每种测试类型在运行时，会调用一个内部的固定测试逻辑，而不是自由配置字段。因此旧版采样器的操作非常有限，在生产环境多建议用"User Defined Test"或"LDAP Extended"。

下面分别介绍四种模式。

1. Add Test（添加测试）

用于创建一个 LDAP 条目。注意：旧版 Add Test 属于"预定义操作"，意味着属性格式是固定的。

通常 JMeter 会创建如下结构的 Entry：

复制代码 
dn: <DN 字段 + 动态生成>
objectClass: inetOrgPerson
sn: somevalue
cn: somevalue

限制：

  • 无法自定义属性

  • 无法添加复杂对象

  • 无法设置 objectClass 列表

适用于：

  • 压力测试（大量写入）

  • 目录数据库写入能力测试

不适用于：

  • 需要精确字段的业务测试
2. Delete Test（删除测试）

删除由 DN 字段指定的 LDAP Entry。

删除逻辑相对简单：

  • 若 DN 不存在 → 错误码：32（No Such Object）

  • 若无权限 → 错误码：50（Insufficient Access Rights）

默认执行以下固定模式的搜索：

  • 使用 DN 作为 Base DN

  • 使用 (objectClass=*) 作为 Filter（不可更改）

  • Scope 默认是 Subtree

意味着搜索所有条目。

限制：

  • 不能自定义 Filter

  • 不能指定 Attributes

  • 不能指定 Scope

如果需要可控的搜索条件，应使用 User Defined Test 或 LDAP Extended Request。

4. Modify Test（修改测试）

执行一次固定格式的 Modify 操作，通常是修改一个字段（比如 cn 或 sn）。

限制同样明显：

  • 无法选择属性

  • 无法执行 ADD/REPLACE/DELETE 精确操作

  • 无法修改多字段

三、User Defined Test（自定义测试）

✔ 这是旧版 LDAP Request 最强大的功能

✔ 专门用于自定义 LDAP 操作

✔ 支持自由编写属性、ObjectClass、Filter 等内容

启用该选项后，界面会出现一个文本框，你可以手工编写 LDAP 请求。

例如：

自定义 Add

复制代码 
dn: uid=john,ou=users,dc=company,dc=com
objectClass: inetOrgPerson
sn: John
cn: John Smith
mail: john@company.com

自定义 Search

复制代码 
baseobject: ou=users,dc=company,dc=com
scope: subtree
filter: (uid=john)
attrs: cn,mail,sn

自定义 Modify

复制代码 
dn: uid=john,ou=users,dc=company,dc=com
changetype: modify
replace: mail
mail: john_new@company.com

自定义 Delete

复制代码 
dn: uid=john,ou=users,dc=company,dc=com
changetype: delete

与 LDAP Extended Request 的区别：

项目 LDAP Request LDAP Extended Request
自定义操作 支持 支持（更灵活）
GUI 配置项 少 完整字段可视化
推荐使用场景 老脚本兼容 新脚本强烈推荐使用

四、适用场景总结

测试模式 适合用途 不适合用途
Add Test 高并发写入压力 精确字段创建
Delete Test 批量删除压力 有条件删除
Search Test 广泛搜索压力 精确过滤条件
Modify Test 修改压力 多字段修改
User Defined Test ✔全功能 LDAP 操作 无

LDAP Extended Request ------ JMeter 最全面的 LDAP 操作采样器详解

在 JMeter 的目录服务测试组件中，LDAP Extended Request 是功能最完整、最现代化的 LDAP/AD 采样器。该组件支持从基础的用户登录验证，到复杂的查询、修改、重命名等全套 LDAP 操作，是进行目录服务性能、稳定性以及业务功能验证的首选工具。

一、界面总览

新版 LDAP Extended Request 主要分为两大区域：

  • Test Configuration（操作配置）

  • Test（选择具体的 LDAP 操作类型）

如下图（你提供的截图）：

Test Configuration

  • Thread Bind

  • Thread Unbind

  • Single bind/unbind

  • Rename entry

Test

  • Add Test

  • Deletion Test

  • Search Test

  • Compare

  • Modification Test

这些选项共同组成了 LDAP Extended Request 的核心功能。

二、Test Configuration（测试行为配置）

这一部分不是具体操作，而是"测试流程行为"的控制，决定了请求如何进行绑定（Bind）和解绑（Unbind）。LDAP 操作必须在 Bind 下完成。

下面对每个开关做完整说明。

1. Thread Bind（线程绑定）

开启后：

  • 每个线程启动时执行一次 Bind（登录）

  • 后续所有 LDAP 操作复用该会话

适合：

  • 高频查询

  • 需要会话复用的 AD 系统

  • 压测业务登录后持续操作

优点： 性能高，减少了每次操作重新 Bind 的消耗。
缺点： 对连接池要求高，服务器必须保障长链路稳定。

2. Thread Unbind（线程解绑）

开启后：

  • 在线程结束时执行 Unbind（退出登录）

一般与 Thread Bind 一起使用：

复制代码 
Thread Start -> Bind -> 多次操作 -> Unbind -> Thread End
3. Single bind/unbind（单次绑定）

如果勾选此项：

  • 每个请求都会进行一次完整的 Bind → 操作 → Unbind

适合：

  • 功能测试（非压力测试）

  • 长链路不稳定的 LDAP 服务

  • 不需要复用连接的情况

注意： 适用功能测试，不适合高并发压力。

4. Rename Entry（重命名条目）

如果你选择了"Rename entry"，界面将出现：

  • Old DN

  • New RDN

  • New Superior（可选）

  • Delete old RDN（布尔值）

适用于：

  • AD 中重命名用户（如从"test1"改成"test2"）

  • LDAP 组织结构迁移（移动 OU、组等）

示例：

复制代码 
旧 DN: uid=john,ou=users,dc=example,dc=com
新 RDN: uid=john_smith
新 Superior: ou=employees,dc=example,dc=com

三、Test（具体 LDAP 操作类型）

这里是核心功能区，你需要在以下几项中选择一个来执行某种 LDAP 操作：

  • Add Test

  • Deletion Test

  • Search Test

  • Compare

  • Modification Test

下面逐一解释。

1. Add Test（添加条目）

用于插入一个新的 LDAP 记录。

会显示：

  • Entry DN

  • ObjectClass 列表

  • 多个 Attribute（key-value）

示例场景：

  • 创建新用户

  • 批量插入组织结构

  • 初始化 LDAP 测试数据

2. Deletion Test（删除条目）

用于删除一个 DN 对象。

参数：

  • Entry DN

注意事项：

  • 仅能删除无子节点的条目（叶子节点）

  • 否则返回错误 66：Not Allowed On Non-leaf

示例：

复制代码 
uid=john,ou=users,dc=example,dc=com

LDAP 最常用的操作之一。

会出现：

  • Base DN

  • Filter（LDAP filter）

  • Scope（base、one、subtree）

  • Attributes（返回哪些属性）

  • Size limit / Time limit（可选）

示例 Filter：

复制代码 
(&(objectClass=inetOrgPerson)(mail=*@example.com))

场景：

  • 用户列表查询

  • 权限过滤

  • 登录前用户验证

4. Compare（属性比对）

Compare 操作用于判断一个属性是否具有某个值。

字段：

  • Entry DN

  • Attribute Name

  • Expected Value

示例：

复制代码 
DN: uid=john,ou=users,dc=example,dc=com
Attribute: userAccountControl
Value: 512

用途：

  • 查询用户是否被锁定

  • 判断账号状态

  • 权限标签检查

5. Modification Test（修改条目）

用于更新已有条目的属性。

包含：

  • Entry DN

  • 多条 Modification（type: Add / Replace / Delete）

  • 每条修改的 Attribute 名和值

示例：

  • 替换邮箱

  • 新增手机号

  • 删除某个属性

示例操作：

复制代码 
replace: mail
mail: john_new@example.com

add: telephoneNumber
telephoneNumber: 123456

四、总结

新版 LDAP Extended Request 基本覆盖所有 LDAP/AD 操作类型：

功能 是否支持
Bind / Unbind ✔
Add ✔
Delete ✔
Modify ✔
Search ✔（高级过滤）
Compare ✔
Rename Entry ✔

并且支持：

  • 单次绑定

  • 线程绑定

  • 高并发长连接

  • 多属性编辑

  • 完整对象类定义

JSR223 Sampler 全面详解

在 JMeter 的众多采样器中，JSR223 Sampler 是最灵活、最强大、可扩展性最高的组件。它允许用户通过脚本语言直接构建请求、控制流程、处理数据，是实现定制化压测方案的核心能力。

与 HTTP、JDBC、TCP 等特定协议采样器不同，JSR223 Sampler 并不绑定任何协议，这也意味着它可以用于几乎所有类型的测试场景------无论是自定义协议、复杂业务逻辑、签名算法，还是预处理、后处理的高级数据操作。

一、JSR223 Sampler 的定位与使用场景

JSR223 Sampler 更像是一个"万能采样器"。它能做的事情包括但不限于：

1. 构建自定义协议请求

当被测系统使用TCP二进制包、私有报文、MQ协议、设备通信协议（如 Modbus）的场景时，无法使用 JMeter 现有采样器，这时 JSR223 成为唯一选择。

2. 实现复杂业务逻辑

例如：

  • 参数动态生成

  • 签名加密、哈希计算

  • 复杂数据结构构建

3. 执行外部接口或工具

如直接调用 Java 类、脚本文件、算法模块、外部 JAR。

4. 实现流程控制

可以在脚本中控制请求行为、设置状态、终止线程、动态跳转等。

5. 替代性能较低的 Beanshell

Beanshell 已过时且性能低下，而 Groovy 的运行性能接近原生 Java。

结论：JSR223 是 JMeter 最具扩展性的核心组件，是构建企业级、定制化性能测试的必备工具。

二、JSR223 Sampler 组件结构与参数解释

在 JMeter 中添加 JSR223 Sampler 后，你将看到以下核心配置项：

1. Name（名称）

采样器的显示名称，建议保持规范便于阅读，如：

  • Generate Sign

  • Custom Packet Builder

  • Groovy PreProcess

2. Script Language（脚本语言）

JMeter 支持多种语言，如：

  • Groovy（推荐）

  • JavaScript

  • JEXL

  • Beanshell（不推荐）

其中 Groovy 具有最高的执行效率和最佳支持，并且与 Java 完全兼容。

官方建议：所有脚本统一用 Groovy。

3. Script（脚本内容）

这是最核心的区域，用于编写执行逻辑。

通过脚本可以访问所有 JMeter 内置对象，例如：

  • vars：JMeter 变量

  • props：全局属性

  • sampler：当前采样器 SampleResult

  • prev：上一个请求结果

  • log：日志对象

  • ctx：采样器上下文

JSR223 的强大正是来自于这些对象提供的可操控能力。

4. Parameters 与 File name（可选）

  • Parameters：通过 args[] 传递参数到脚本

  • File name：加载外部 Groovy 文件，适合大型项目或复用脚本

5. Script compilation caching（脚本缓存）

这是 JSR223 性能的关键。

勾选后，Groovy 脚本会被编译成字节码并缓存，后续执行无需再次编译，性能接近 Java 原生速度。

三、JSR223 Sampler 的执行机制

要理解 JSR223 的性能差异，需要了解它的脚本执行方式。

1. Groovy：编译执行（推荐）

  • JMeter 启动时加载 Groovy 引擎

  • 脚本执行时先编译成字节码

  • 缓存后直接运行字节码

  • 速度接近 Java

2. Beanshell：解释执行（非常慢）

每次运行都要逐行解释，严重影响性能。

3. JavaScript 等语言：性能不稳定

依赖 Rhino/Nashorn，效率不高，也不适合高并发。

因此，正确的用法是：使用 Groovy + 开启 Script Caching。

四、JSR223 中常用的内置对象

JSR223 Sampler 中的脚本可以直接使用许多 JMeter 运行时对象，用于访问变量、输出日志、修改采样器结果等。

以下是最常用的对象说明：

对象 描述
vars JMeter 变量容器，管理 ${var}
props 全局属性，适合跨线程组共享数据
prev 上一个采样器的 SampleResult
sampler 当前采样器的 SampleResult，可用于自定义响应
log JMeter 日志
ctx JMeter 上下文，包含线程、取样器信息
Thread.sleep() 可实现等待或节奏控制
System.currentTimeMillis() 可实现时间戳、计时逻辑

五、JSR223 使用中的最佳实践

为了让 JSR223 在高并发场景下运行稳定、性能最佳，建议遵循以下最佳实践。

1. 统一使用 Groovy

Groovy 是 JMeter 中唯一能提供接近 Java 性能的脚本语言。

2. 必须开启 Script Caching

这是提升 5~50 倍性能的关键步骤。

3. 避免在脚本中重复创建对象

特别是在循环或高并发场景中，频繁创建 JsonSlurper 等工具对象会导致 GC 压力。

推荐使用注解方式缓存对象：

复制代码 
@Field def slurper = new JsonSlurper()

4. 不要在脚本中写大量日志

过多日志会直接影响性能和吞吐量。

5. 不要把 JSR223 当作 HTTP Sampler 替代品

除非你需要：

  • 复杂签名

  • 构造动态请求体

  • 模拟自定义逻辑

否则应优先使用原生采样器。

6. 将公共脚本封装为外部文件

比如签名算法、公共工具、加密解密逻辑等。

适合集成到大型测试框架中。

六、何时应该使用 JSR223 Sampler？

以下情况优先使用 JSR223：

  • 协议本身无法由 JMeter 支持

  • 需要复杂的数据构造或算法

  • 需要自定义 SampleResult

  • 涉及高级流程控制或动态测试逻辑

  • 需要与外部组件集成，例如数据库驱动、SDK、JAR 包

而以下情况不建议使用：

  • 普通 HTTP 调用

  • 普通 SQL 测试

  • 简单参数传递（可用 User Parameters 解决）

七、总结

JSR223 Sampler 是 JMeter 生态中最灵活、最强大、也是最容易写出高性能脚本的组件。它通过 Groovy 的高兼容性和运行效率，为性能测试工程师提供了无限扩展能力。

使用得当，它可以代替大量冗余流程，实现：

  • 自定义协议支持

  • 动态数据处理

  • 自定义测试逻辑

  • 灵活的流程控制

  • 高度可扩展的脚本化测试体系

正确使用 JSR223，可以让你的 JMeter 测试框架完全进入"可编程时代"。

JMeter BeanShell Sampler 全面详解（不推荐，但必须了解）

在 JMeter 的早期版本中，BeanShell Sampler 是脚本化扩展 JMeter 的主要方式。它能通过 BeanShell（基于 Java 的脚本语言）执行脚本，实现请求构造、数据处理、变量管理等功能。

但随着 JMeter 的发展，官方已经明确建议使用 JSR223 + Groovy 替代 BeanShell，因为后者存在性能低下、内存占用高、引擎过时等问题。

尽管如此，BeanShell Sampler 仍然在许多老项目或企业测试体系中被大量使用，因此理解它非常重要。

一、BeanShell Sampler 的作用与定位

BeanShell Sampler 的功能非常类似于 JSR223 Sampler：

它能让你在测试中编写脚本，用于创建请求、控制逻辑、处理数据。

但与 JSR223 不同：

特性 BeanShell JSR223（Groovy）
性能 较慢，解释执行 高速，编译执行
线程安全 差 好
稳定性 最低，容易报错 高
是否推荐 ❌ 不推荐 ✔ 推荐
是否未来维护 几乎不会 持续更新

总结：BeanShell Sampler 属于"过渡时代产物"，不适合高并发场景，但仍需理解它的配置和运行方式。

二、BeanShell Sampler 的典型使用场景

尽管 BeanShell 已经过时，但仍然存在于一些老旧测试体系或公司内部测试框架中。常见使用场景包括：

1. 老项目脚本的兼容性需求

许多历史遗留的性能测试脚本使用 BeanShell，因此需要继续维护或兼容。

2. 简单数据操作

例如：

  • 设置变量

  • 修改请求参数

  • 拼接字符串

3. 轻量逻辑控制

而非高并发、复杂数据处理。

对于企业中需要逐步现代化迁移的测试体系，理解 BeanShell Sampler 有助于将旧脚本迁移到 JSR223。

三、BeanShell Sampler 配置项详解

当选择 Sampler → BeanShell Sampler 后，会看到如下配置项：

1. Name（名称）

采样器名称，如：

  • Legacy Data Script

  • Custom BeanShell Logic

2. Parameters（参数）

用于传递数据到脚本内部，可通过 bsh.args 数组读取。

适合很小规模的参数传递。

3. Script File（脚本文件）

支持引用一个外部 .bsh 文件，适合较长脚本，也更易维护。

4. Script（脚本内容）

编写 BeanShell 脚本的核心区域。

脚本可以使用许多预定义对象，例如：

对象 说明
vars JMeter 变量
props JMeter 全局属性
sampler 当前采样器
prev 上一个采样器结果
log 日志对象
ctx JMeter 上下文

BeanShell 与 Java 语法高度相似，因此脚本通常"看起来像 Java"。

四、BeanShell 的执行机制（为什么慢？）

BeanShell 是一种"解释执行"的脚本语言：

  • 每次运行脚本时都需要重新解释代码

  • 没有缓存、没有编译

  • 每个线程执行一次 BeanShell 都要重新解释代码

在高并发场景下这会导致：

  • CPU 飙升

  • 内存消耗巨大

  • GC 频繁触发

  • JMeter 性能严重下降

  • 甚至导致测试机崩溃

这也是 JMeter 官方明确不推荐使用 BeanShell 的核心原因。

五、BeanShell Sampler 的风险与常见问题

1. 性能极差

尤其是循环中进行复杂运算时。

2. 不支持脚本缓存

每次执行都是重新解释代码。

3. 线程不安全

BeanShell 引擎在多线程并发下容易产生冲突。

4. 依赖性弱

许多现代 Java 类库可能无法与 BeanShell 良好兼容。

5. 大量占用 CPU

在大规模压测时，瓶颈常出现在"脚本执行"，而不是被测系统。

六、最佳实践（如果你必须使用 BeanShell）

尽管不推荐，但为了兼容老脚本，有时必须继续使用 BeanShell。以下是最佳实践：

1. 脚本尽可能简单

不要在 BeanShell 中做：

  • JSON 解析

  • 大规模字符串处理

  • 加解密

  • 网络请求

  • 高耗时运算

2. 能移到 JSR223 的逻辑尽量移走

特别是：

  • 密集计算

  • 长脚本

  • 重复执行代码

3. 日志输出必须减少

BeanShell 的日志 IO 会进一步拉低性能。

4. 尽量使用 Script File 而不是内联代码

可以让脚本更易替换为 Groovy。

5. 对老脚本进行分阶段迁移

迁移策略建议：

  1. 保留基础逻辑

  2. 将复杂部分迁移至 JSR223

  3. 完全用 Groovy 替代 BeanShell

七、BeanShell Sampler 是否应该继续使用？

如果是新项目 → 绝对不要使用 BeanShell。

只有以下情况下才需要：

  • 老脚本必须兼容

  • 测试体系是十年前的版本

  • 测试环境依赖历史 BeanShell 工具类

现代 JMeter 的统一推荐方案是：

✔ JSR223 Sampler + Groovy

这是官方、社区、企业实践的标准配置。

八、总结

BeanShell Sampler 是 JMeter 历史遗留组件，虽能满足脚本化需求，但受限于性能和技术老化：

  • 解释执行导致性能极低

  • 不适合高并发

  • 容易造成 CPU/内存瓶颈

  • 不推荐用于新项目

  • 最好逐步迁移到 JSR223

在现代性能测试体系中，BeanShell Sampler 的主要价值是------

让你能读懂甚至迁移老旧脚本，而不是继续使用它。

Java Request Sampler 全面详解：适用于自定义协议的终极扩展方式

在 JMeter 的所有取样器（Sampler）中，Java Request Sampler 是最特殊的一类。

它不像 HTTP、JDBC、JMS 那样针对特定协议，而是允许你：

通过 Java 编写一个完整的 Sampler 插件，并在 JMeter 中直接调用。

这意味着：

  • 任何协议

  • 任何格式

  • 任何业务流程

  • 任何特殊逻辑

只要你能用 Java 写出来，就可以作为 JMeter 的一个自定义采样器执行。

因此，Java Request Sampler 对应的使用场景非常明确：

✔ 企业内部自定义协议

✔ 私有 RPC

✔ 二进制协议

✔ 需要执行本地 Java 方法

✔ JMeter 无法原生支持的测试逻辑

它是实现定制化负载测试的最底层能力。

一、Java Request Sampler 的工作机制

与其他采样器不同，Java Request Sampler 不会执行脚本或发送网络请求 。

它做的是：

  1. 你写一个 Java 类，实现 JavaSamplerClient

  2. 将编译后的 .class 或 .jar 放入 JMeter 的 /lib/ext/

  3. JMeter 加载该类，显示为可选项

  4. 运行测试时调用你写的方法

JMeter 会调用以下方法：

方法 作用
setupTest() 测试前准备（如连接池初始化）
runTest() 真正的取样逻辑
teardownTest() 测试结束资源释放

结果通过 SampleResult 返回，包括：

  • 响应码

  • 响应消息

  • 响应时间

  • 自定义响应数据

换句话说，你写的 Java 类就像是一个插件式的"迷你采样器"。

二、Java Request 的适用场景

1. 私有协议性能测试

例如：

  • 企业自研 RPC 框架

  • 嵌入式设备专用二进制协议

  • 金融行业专线数据包格式

这些协议通常不属于 JMeter 的原生支持范围，因此 Java Request Sampler 是唯一方式。

2. 调用本地 Java 逻辑进行复杂业务流程模拟

例如：

  • 加密/解密测试

  • 调用本地算法

  • 本地模拟某种请求封装

  • Java SDK 的性能测量

3. 测试无需网络的功能

例如：

  • 压测一个本地算法

  • 压测一个缓存组件操作

  • 压测 JNI 方法

4. 作为自定义采样器开发的过渡方式

许多企业开发自己的 JMeter 插件时，会先使用 Java Request Sampler 原型开发。

三、Java Request Sampler 配置项详解

进入 Samplers → Java Request 后可看到以下内容。

1. Name（名称）

采样器名称。

2. Classname（类名）

JMeter 会读取 /lib/ext/ 中所有实现了 JavaSamplerClient 的类，并显示在下拉框中。

你需要从中选择你自定义的类。

3. Parameters（参数）

可向你的 Java 类传入 key-value 参数。

例如：

Name Value
host 10.0.0.5
timeout 2000

你的类中可通过：

复制代码 
arguments.getArgument("host");

获取这些参数。

四、自定义 Java Sampler 的设计原则

虽然很多人仅把 Java Request 当"万能工具"，但是要写得好------仍需遵循一些最佳实践。

1. 逻辑必须足够轻量

Java Request 运行于 JMeter 内部线程池中。

如果你执行：

  • 大规模 IO

  • 大量对象创建

  • CPU 密集计算

都会导致 JMeter 本身性能下降，甚至阻塞线程池。

2. 不要在 runTest() 中做初始化

初始化（例如连接数据库）应该放在：

  • setupTest()

  • 或全局静态块

否则每个线程都会重复初始化，严重拖慢性能。

3. runTest() 必须只做"一个样本"的工作

否则：

  • TPS 无法计算

  • 响应时间失真

  • 线程组控制器失效

4. 必须正确返回 SampleResult

包括：

  • setResponseCode()

  • setResponseMessage()

  • setSuccessful()

否则在查看结果树或报告时会出现异常数据。

五、Java Request Sampler 的优点

✔ 不受协议限制

想测什么就测什么。

✔ 性能高、稳定度强

因为是纯 Java 编译执行，比脚本类 Sampler 稳定得多。

✔ 支持复杂业务流程

可以执行任意复杂逻辑。

✔ 与企业内部代码无缝集成

能直接调用 SDK、工具类等。

六、Java Request Sampler 的缺点

❌ 开发成本高

必须编写 Java、打包、部署。

❌ 侵入性强

把业务 SDK 放进 JMeter，容易导致依赖冲突。

❌ 不适合多人协作

每次更新都要重新构建 jar 包。

❌ 不如 JSR223 灵活

Groovy 更适合快速迭代。

七、Java Request vs JSR223 Sampler

项目 Java Request JSR223（Groovy）
性能 ✔ 高 ✔ 高
灵活性 中 极高
开发成本 高 低
适合复杂协议 ✔ 是 否
适合快速开发 否 ✔ 是
是否需要编译 ✔ 需要 否
是否易协作 差 好

总结：
Java Request 适合"必须用 Java 写"的情况，否则 JSR223 更合理。

八、典型使用流程总结

企业中使用 Java Request 的典型步骤：

  1. 创建 Java 类（实现 JavaSamplerClient）

  2. 编译并打包成 jar

  3. 放到 JMeter 的 lib/ext/

  4. 重启 JMeter

  5. 在 Java Request 下拉框中选择类

  6. 配置参数

  7. 执行压测

这是 JMeter 最专业、最可扩展的扩展方式。

九、总结

Java Request Sampler 是 JMeter 中扩展能力最强、限制最少的采样器，它提供：

  • 最大的灵活性

  • 最底层的扩展能力

  • 支持任何协议、SDK 或业务逻辑

它适用于：

✔ 企业内部私有协议

✔ 需要自定义采样器逻辑

✔ 需要运行本地 Java 代码

✔ 需要构建插件原型

但由于开发成本较高，不推荐用于日常测试逻辑。

如果能用 JSR223 + Groovy 实现，那么没必要写 Java。

JUnit Request（JUnit 请求采样器）全面解析

JUnit Request 是 JMeter 提供的用于运行 JUnit 测试类的采样器。它允许用户将已有的基于 JUnit 的单元测试直接整合到性能测试流程中，使功能验证与性能测试无缝衔接。对于需要复用已有测试代码、构建业务逻辑级别压测场景的系统而言，JUnit Request 是最重要的 Java 扩展型采样器之一。

一. JUnit Request 的作用

JUnit Request 的核心作用是在 JMeter 中执行指定的 JUnit 测试类，包括：

  • 调用已有的 JUnit 单元测试

  • 复用现有测试框架实现复杂业务操作

  • 在压测过程中执行逻辑验证

  • 结合断言确保系统在高负载下仍保持正确行为

它适用于需要将业务验证逻辑与性能测试结合的场景，而不是用于高吞吐量的协议压测。

二. JUnit Request 的运行机制

JUnit Request 通过以下流程执行：

  1. 在 JMeter 启动时扫描 classpath

  2. 加载目标 JUnit 测试类

  3. 调用 setup、test 方法、tearDown

  4. 记录执行时间、结果、错误信息

  5. 将执行情况写入 SampleResult

其行为高度依赖 JUnit 类本身的逻辑，因此必须保证测试类结构正确。

三. 主要配置参数说明

在 JUnit Request 的界面中，可以配置以下关键字段。

基本信息配置

JUnit Request Name

采样器的名称，用于在测试计划和结果树中标识当前的 JUnit 请求。

Comments

对该采样器的备注说明，可用于记录使用目的、测试说明或维护信息。

测试类加载与查找方式

Search for JUnit 4 annotations

启用该选项后，采样器将按照 JUnit 4 规范进行方法扫描，包括识别：

  • @Test

  • @Before

  • @After

  • @BeforeClass

  • @AfterClass

若使用 JUnit 4 编写测试，应开启此选项。

Package Filter

用于过滤需要加载的类所在的 package 范围。

在 classpath 较大或包含大量测试类时，通过该参数可以缩小搜索范围，提高加载效率。

Classname

指定要执行的 JUnit 测试类的全限定类名。

该类必须位于 JMeter 的 classpath 内，并符合 JUnit 3 或 JUnit 4 的结构规范。

Constructor String Label

为测试类构造方法提供字符串参数。

适用于测试类在创建时需要特定初始化值的场景。

测试执行控制

Test Method

指定要执行的具体测试方法名称。

对于 JUnit 4，可选择任意带 @Test 注解的方法；对于 JUnit 3，则需符合 testXXX 命名规范。

Do not call setUp and tearDown

启用后，采样器不会调用：

  • setUp()（初始化）

  • tearDown()（清理）

适用于希望测试方法独立执行、不需要生命周期逻辑的场景。

Create a new instance per sample

启用后，JMeter 在每次采样时创建该测试类的新实例。

适合包含状态的测试类，避免实例共享导致执行结果不一致。

结果消息与状态码配置

JUnit Request 允许通过自定义消息与状态码来标识测试结果，从而在断言与结果分析中提供更直观的信息。

以下四组参数分别对应成功、失败、错误三种状态。

Success Message

当测试成功时显示的文字描述。

示例默认值为：Test successful

Success Code

成功状态对应的代码，用于报告区分。

默认值：1000

Failure Message

当测试断言失败时的描述信息。

默认值：Test failed

Failure Code

断言失败对应的状态码。

默认值：0001

Error Message

当执行过程中出现未捕获异常时的描述信息。

默认值：An unexpected error occurred

Error Code

非预期异常对应的状态码。

默认值：9999

错误信息附加选项

Append assertion errors

启用后，采样器会将断言失败的具体信息附加到响应消息，用于定位测试原因。

Append runtime exceptions

启用后，执行过程中产生的异常信息会附加到结果中，便于分析错误源头。

四. 使用 JUnit Request 的典型场景

JUnit Request 并非协议采样器，因此适用于以下场景：

4.1 复用已有单元测试

系统已有大量功能性 JUnit 测试，希望直接利用这些方法构建性能验证流程。

4.2 复杂业务操作的压测驱动

某些系统调用链复杂，例如调用多个微服务或数据库，通过 JUnit 可以统一封装逻辑。

4.3 高负载条件下验证业务正确性

将断言写入 JUnit 测试中，在压测期间自动校验业务状态，确保系统在压力下仍保持一致性。

4.4 非常规协议压测

适用于需要自行构建逻辑、协议或测试模型的场景，该功能提供了最大自由度。

五. JUnit Request 的限制

尽管 JUnit Request 功能灵活，但存在以下限制：

  • 不适合高并发协议压测

  • 性能与 JVM 执行效率有关

  • JUnit 方法中包含的大量日志可能造成阻塞

  • 单次执行逻辑较重时会影响整体 TPS

因此应合理用于业务逻辑验证，而不是作为协议层压测工具。

六. 总结

JUnit Request 是 JMeter 中用于执行 Java 单元测试的重要采样器，通过它可以无缝复用已有测试代码、整合业务验证逻辑，并在性能测试流程中保持与开发测试一致的测试行为。该采样器在构建复杂逻辑场景、执行业务校验和运行自定义 Java 测试流程方面具有显著优势。

Debug Sampler（调试采样器）详解

在构建复杂测试计划时，变量的作用域、参数的传递方式、脚本计算的结果等常常需要实时验证。JMeter 提供的 Debug Sampler 正是为此而生的，它不会向外部系统发送请求，而是用于输出当前线程上下文中的各种信息，包括 JMeter 变量、JMeter 属性、JMeter 函数处理结果等。

该采样器主要用于调试测试脚本 、查看变量值 、验证前置/后置处理器输出 、排查提取器是否生效等场景。

一、Debug Sampler 的作用

Debug Sampler 的主要用途包括：

1. 查看 JMeter 变量

例如：

  • 上一步提取器生成的变量

  • CSV Data Set Config 加载的字段

  • 用户参数组件创建的变量

适用于验证变量是否正确传递到当前线程。

2. 查看 JMeter 属性

用于排查环境参数、全局属性文件、启动参数等是否正确加载。

3. 查看当前线程组的上下文信息

包括：

  • 当前线程名

  • 线程组名

  • 采样器层级信息

这些信息对于调试多线程、循环、逻辑控制结构非常有帮助。

4. 输出测试计划中的执行内容

当你希望确认脚本结构、变量加载顺序或执行顺序时，Debug Sampler 能提供第一手信息。

二、核心配置项说明

Debug Sampler 本身配置项非常简单，核心参数如下：

1. Name（名称）

采样器显示名，建议根据调试目的命名，例如：

  • Debug --- Check CSV

  • Debug --- Check Extractor Output

  • Debug --- Global Vars

2. Display Variables（显示变量）

用于选择要输出的变量类型：

选项 说明
JMeter Variables 输出当前线程所有变量（最常用）
JMeter Properties 输出全局属性
System Properties 输出 JVM 系统属性
Sampler Properties 输出采样器自身的参数
Test Plan Tree 输出测试计划结构
JMeter Context 输出上下文信息（线程名、取样器信息等）

可以自由组合勾选，默认情况下显示 JMeter Variables。

三、典型使用场景

1. 调试提取器是否正常工作

在正则提取、JSON 提取、XPath 提取等后处理器之后放置 Debug Sampler，可检查提取的变量是否存在或格式是否正确。

2. 检查用户自定义变量和函数执行结果

例如：

  • __UUID() 是否生成唯一 ID

  • 函数计算值是否正确

  • 参数化变量是否按预期加载

3. 排查脚本中的变量覆盖问题

当脚本过于复杂时，不同组件可能会覆盖同名变量，通过 Debug Sampler 可轻松找到来源。

4. 分析脚本结构执行顺序

勾选 Test Plan Tree 后，可看到完整的测试计划结构，用于确认脚本组织是否合理。

四、在监听器中查看输出

将 Debug Sampler 与以下监听器配合能够更直观：

  • View Results Tree

  • View Results in Table

  • Simple Data Writer

输出内容将以文本方式显示，方便跟踪变量值变化。

五、最佳实践

  1. 调试阶段使用，正式压测时务必关闭

    Debug Sampler 输出内容大量且对性能有影响。

  2. 放在关键步骤之后

    例如提取器之后、变量设置之后、脚本逻辑较复杂的循环内部。

  3. 命名清晰，便于搜索

    避免多个 Debug Sampler 混淆。

  4. 只勾选必要的输出类型

    系统属性等信息体量庞大，除非需要排查，否则不建议勾选。

OS Process Sampler（操作系统进程采样器）详解

OS Process Sampler 是 JMeter 中用于在测试过程中调用 操作系统级命令或外部可执行程序 的采样器。

它允许在测试计划中执行 Shell 脚本、批处理文件、可执行程序或任何系统命令，从而扩展 JMeter 的测试能力，例如调用外部工具、启动系统任务、触发脚本分析、生成数据等。

不同于普通协议采样器，OS Process Sampler 不与网络系统交互，而是直接向操作系统发起进程调用，因此常用于 辅助性任务执行与测试前置/后置操作。

一、核心功能与作用

OS Process Sampler 在测试场景中主要使用于：

1. 执行外部命令或脚本

例如：

  • 在 Linux/Unix 调用 .sh

  • 在 Windows 调用 .bat 或 .exe

  • 执行系统工具（如 ping、curl、ffmpeg、python 等）

适合进行一些 JMeter 本身无法直接实现或难以实现的操作。

2. 动态生成输入数据或环境准备

如：

  • 启动后台服务

  • 动态写文件、生成数据

  • 清理旧日志、删除临时文件

  • 自动部署或初始化测试资源

3. 执行测试后的清理工作

例如：

  • 停止外部进程

  • 重置测试环境

  • 执行收尾脚本

4. 结合参数化实现灵活操作

JMeter 变量可作为命令参数传递，使脚本执行具有动态性。

二、OS Process Sampler 参数说明

OS Process Sampler 的配置项相对简单，但功能非常灵活。

Command to Execute（要执行的命令）

这是 OS Process Sampler 的核心配置，用于指定要执行的系统命令或程序。

Command（命令）

填写要执行的可执行程序或系统命令。

可以包含绝对路径，也可以是系统 PATH 中可直接调用的命令名称。

Working Directory（工作目录）

指定程序运行时的工作目录。

若留空，则使用 JMeter 启动目录作为默认工作目录。

Command Parameters（命令参数）

命令参数以列表形式维护，一行对应一个参数。

参数按顺序传递给 Command，支持使用 JMeter 变量。

字段操作说明：

  • Value：单个参数内容。

  • Detail：查看或编辑参数的详细文本。

  • Add / Delete：添加或删除参数行。

  • Add from Clipboard：从剪贴板批量导入参数。

  • Up / Down：调整参数顺序。

此区域的参数最终将按照顺序传递给命令执行。

Environment Variables（环境变量）

为命令执行设置进程级环境变量。

结构与参数区一致，支持逐项编辑和排序。

每个环境变量以 Name=Value 的格式定义，例如：

  • MODE=prod

  • PATH=/usr/local/bin

Standard Streams（标准流配置）

可将命令运行过程的标准输入、标准输出、标准错误重定向到文件。

1. Standard input (stdin)

指定一个文件作为命令的标准输入内容。

2. Standard output (stdout)

命令标准输出内容写入指定文件，而不是显示在响应数据中。

3. Standard error (stderr)

错误输出写入指定文件，便于日志分离与错误排查。

Return Code Configuration（返回码配置）

用于控制采样结果的成功或失败判断。

1. Check Return Code（检查返回码）

启用后，JMeter 会根据返回码判断采样是否成功。

2. Expected Return Code（期望返回码）

默认值为 0。

当命令返回的退出码与此值一致时，采样被视为成功；否则视为失败。

3. 操作按钮（Detail / Add / Delete / Up / Down）

用于管理返回码相关配置条目。

Timeout Configuration（超时）

Timeout (ms)

为命令执行设置最大允许时间（毫秒）。

超时后 JMeter 会强制终止命令，并将采样标记为失败。

三、采样结果中的重要信息

在监听器（View Results Tree）中可以看到：

  • 请求体：执行的命令与参数

  • 响应数据：命令行的输出内容

  • 退出码

  • 执行耗时

  • 标准错误输出（stderr）

这些信息可用于排查命令是否执行成功。

四、典型使用场景概述

下面列出常见的使用目的（不列举具体脚本内容）：

1. 测试环境准备

  • 创建目录

  • 复制数据文件

  • 动态生成业务数据

2. 调用外部程序实现复杂处理

如：

  • 视频转码

  • 加密/解密处理

  • AI/ML 模型调用

  • CLI 工具驱动的业务任务

3. 调用系统命令监控服务器状态

例如执行系统工具获取 CPU/内存快照，用于对比压测期间系统状态变化。

4. 压测流程中的前置和后置动作

如：

  • 压测开始前启动后台服务

  • 压测结束后执行清理脚本

五、最佳实践

  1. 命令尽量使用绝对路径，防止 PATH 差异导致脚本无法执行。

  2. 避免在高并发场景大量使用 OS Process Sampler，它会消耗系统资源。

  3. 在脚本中规范退出码，便于 JMeter 自动判断成功或失败。

  4. 不要输出过多日志（stdout/stderr），否则监听器会产生巨大结果数据。

  5. 结合变量引用 实现动态命令，例如传入用户 ID、文件名、时间戳等。

JMeter Sampler 全面总结

Sampler 是 JMeter 的"执行引擎"，定义了用户在系统中执行的每一个操作。它负责发起请求并产出 SampleResult，是所有断言、监听器和报告的基础。本章介绍了各类官方采样器（HTTP、TCP、FTP、JDBC、JMS、邮件、系统命令等）及其使用场景，同时说明了统一的执行流程与输出结构。

理解 Sampler 的核心机制，可以帮助测试人员构建更准确的性能场景，实现对各种协议的完整覆盖，并在结果分析中做出可靠判断。Sampler 是 JMeter 测试脚本的绝对核心模块。

相关推荐
玖釉-1 天前
JMeter 测试计划（Test Plan）与脚本结构详解
jmeter
天才测试猿2 天前
Jmeter命令行压测&生成HTML测试报告
软件测试·测试工具·jmeter·职场和发展·jenkins·测试用例·压力测试
@Dream-fennel2 天前
WebSocket教程：如何使用JMeter进行压力测试
websocket·jmeter·压力测试
程序员三藏2 天前
Jmeter的三种参数化方式
自动化测试·软件测试·python·测试工具·jmeter·测试用例·压力测试
西江649763 天前
【个人博客系统—测试报告】
python·功能测试·jmeter·pycharm·postman
天才测试猿4 天前
Jmeter压测实战：Jmeter二次开发之自定义函数
自动化测试·软件测试·python·测试工具·jmeter·职场和发展·压力测试
玖釉-4 天前
JMeter 简介
jmeter
玖釉-4 天前
JMeter 安装与环境配置
jmeter
热门推荐
01GitHub 镜像站点02【超详细教程】手把手教你从微软官网免费下载Windows 10官方原版ISO镜像（2025最新版）03安娜的档案(Anna’s Archive) 镜像网站/国内最新可访问入口（持续更新）04UV安装并设置国内源05Linux下V2Ray安装配置指南06BongoCat - 跨平台键盘猫动画工具07React CVE-2025-55182漏洞排查与修复指南08从入门到实战：Gemini 3 使用指南速览09本地部署阿里最新开源的Z-Image10在VSCode配置Java开发环境的保姆级教程（适配各类AI编程IDE）