下面有一个具体的实例，如下图所示：
json path extractor
jmeter 通过安装 json path extractor 插件来处理 json 串，提取 json 串中的字段值。插件的下载地址：https://jmeter-plugins.org/?search=jpgc-json，下载完成，解压后，直接把 lib 文件夹放到 jmeter 相应目录下面。特别说明：jmeter 2.xx 左右的版本尝试过无法使用该插件，在 jmeter 3.xx 左右的版本装完插件后能正常使用。
需要在请求下创建后置处理器 - jp@gc-JSON Path Extractor，具体的实例如下所示：
jmeter 操作数据库
操作数据库基本有四个步骤：
（1）导入 mysql 的 jdbc 的 jar 包
（2）创建数据库的连接配置，线程组里添加配置元件 - JDBC Connection Configuration
（3）线程组里添加 jdbc request，写 sql 语句
（4）添加察看结果树，点击启动按钮，就能看到执行的 SQL。具体的实例如下截图所示
特别说明：
jmeter 还可以操作 oracle、postgreSQL、msSQL、mongodb 等等数据库，同时不同的数据库，JDBC Connection Configuration 填写的 Database url 格式和 JDBC Driver 驱动名称也不相同。jmeter 数据库驱动列表如下表所示：
Jmeter-webservice 接口脚本
基本分为五个步骤：(1) 先需要通过 soapui 工具获取到 webservice 接口的请求地址、请求报文和请求 soapaction。 （2）jmeter 新建一个线程组 （3）线程组下建立 SOAP/XML-RPC Request，写入请求 url、请求报文、请求 soapaction。（3）启动 jmeter，调用接口，通过察看结果树查看返回值。
soapui 获取信息的实例如下图所示：
soapui 提交完后，点击 raw, 可看到 soapation，有些接口若没返回 soapation, 则 jmeter 里也就不用填。
jmeter-webservice 脚本实例如下图所示：
六、附加信息
1、jmeter 在 linux 下进行压力测试
1.1、jmeter 在 linux 安装
简单说下，就是要先安装 jdk, 同时再配置环境变量，最后再上传 jmeter 压缩的安装包，在 linux 下解压完安装包就可以使用了。jmeter 在 linux 运行
进入 jmeter 下的 bin 目录下运行脚本，未配置 jmeter 环境变量的条件下，运行的命令：
./jmeter -n -t a.jmx -l res.jtl
其中 a.jmx 是准备好的 jmeter 脚本，res.jtl 是测试结果文件，测试结果文件可以导入到 jmeter 察看结果树下查看。
七、压力测试
1、压力测试场景
压力测试分两种场景：
一种是单场景，压一个接口的；
第二种是混合场景，多个有关联的接口。压测时间，一般场景都运行 10-15 分钟。如果是疲劳测试，可以压一个小时、一天或一周，根据实际情况来定。
2、压测任务需求的确认
压测前要明确压测功能和压测指标，一般需要确定的几个问题：
固定接口参数进行压测还是进行接口参数随机化压测？
要求支持多少并发数？
TPS（每秒钟处理事务数）目标多少？响应时间要达到多少？
2.4、压服务器名称还是压服务器 IP，一般都是压测指定的服务器
3、压测设置
线程数：并发数量，能跑多少量。具体说是一次存在多少用户同时访问
Rame-Up Period (in seconds): 表示 JMeter 每隔多少秒发动并发。理解成准备时长：设置虚拟用户数需要多长时间全部启动。如果线程数是 20，准备时长为 10，那么需要 10 秒钟启动 20 个数量，也就是每秒钟启动 2 个线程。
循环次数：这个设置不会改变并发数，可以延长并发时间。总请求数 = 线程数 * 循环次数
调度器：设置压测的启动时间、结束时间、持续时间和启动延迟时间。
4、压测结果查看
运行完后，聚合报告会显示压测的结果。主要观察 Samples、Average、error、Throughput。
Samples: 表示一共发出的请求数
Average：平均响应时间，默认情况下是单个 Request 的平均响应时间（ms）
Error%: 测试出现的错误请求数量百分比。若出现错误就要看服务端的日志，配合开发查找定位原因
4.4、Throughput: 简称 tps, 吞吐量，默认情况下表示每秒处理的请求数，也就是指服务器处理能力，tps 越高说明服务器处理能力越好。
5、压测结果的分析
有错误率同开发确认，确定是否允许错误的发生或者错误率允许在多大的范围内；
5.1、Throughput 吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；
若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；压测结束，登陆相应的 web 服务器查看 CPU 等性能指标，进行数据的分析；
5.2、最大的 tps: 不断的增加并发数，加到 tps 达到一定值开始出现下降，那么那个值就是最大的 tps。
5.3、最大的并发数：最大的并发数和最大的 tps 是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数。
5.4、压测过程出现性能瓶颈，若压力机任务管理器查看到的 cpu、网络和 cpu 都正常，未达到 90% 以上，则可以说明服务器有问题，压力机没有问题。
5.5、影响性能考虑点包括：数据库、应用程序、中间件（tomact、Nginx）、网络和操作系统等方面。
