本文版权归xmeter.net 所有。欢迎转载，转载请注明出处。
摘要##
JMeter提供了多种方式来自定义脚本来实现JMeter不支持的功能，常见的方式有插入BeanShell脚本和通过扩展JMeter提供的Java接口，本文通过实现一个简单的功能来比较两种不同的实现方式下对JMeter的性能影响，并对这两种不同的实现方式的使用场景提供推荐。
测试场景##
假设测试脚本需要产生一个长度为1024的随机字符串，字符串产生后将其赋值给一个名为“data”的变量，供后面的Sampler来使用，在本文中使用的是“Dummy Sampler”，该Sampler能让用户手工输入“Request Data”和“Response Data”，使用过程中易于调试和测试。BeanShell版的JMeter测试脚本结构如下。需要注意的是Dummy Sampler不是JMeter标准提供的Sampler，读者如果有兴趣，参见https://jmeter-plugins.org 安装步骤将其安装到你的JMeter中。
BeanShell Preprocessor中的代码如下，生成了随机字符串后将值赋值给变量“data”。
在Dummy Sampler里的“Response Data”输入框中传入变量“data”，如下图所示。
Java扩展JMeter的实现方式下，测试脚本的基本结构与上类似，如下图所示，不一样的地方是把“BeanShell Preprocessor”替换成了“User Parameters”。
“User Parameters”下加入一个变量，该变量的值是自定义扩展的一个函数 － “${__MyRandomFunc()}”。
该自定义函数MyRandomFunc的实现方式如下所示，具体请参见这篇文章来学习如何扩展自定义函数。
测试配置##
测试运行之前，将两个测试用例的ThreadGroup的数目设置成100，每个Thread运行100次。
测试机器是在青云上申请的标准虚机：
1）2核CPU＊2GB内存
2）20GB硬盘
3）操作系统CentOS 7，64位
4）Java版本是Open JDK 8
5）JMeter版本是3.0
JMeter测试采用非UI方式运行。
测试结果##
BeanShell执行完测试约用了1分18秒左右，控制台打印出的测试结果如下。JMeter进程CPU使用率为137%，内存使用率为14%.
summary + 2802 in 00:00:23 = 120.6/s Avg: 276 Min: 50 Max: 516 Err: 0 (0.00%) Active: 100 Started: 100 Finished: 0
summary + 4138 in 00:00:30 = 138.1/s Avg: 275 Min: 50 Max: 506 Err: 0 (0.00%) Active: 100 Started: 100 Finished: 0
summary = 6940 in 00:00:53 = 130.5/s Avg: 275 Min: 50 Max: 516 Err: 0 (0.00%)
summary + 3060 in 00:00:24 = 125.9/s Avg: 276 Min: 50 Max: 502 Err: 0 (0.00%) Active: 0 Started: 100 Finished: 100
summary = 10000 in 00:01:18 = 129.0/s Avg: 276 Min: 50 Max: 516 Err: 0 (0.00%)
Java扩展JMeter的实现方式执行完测试约用了32秒，控制台打印出的测试结果如下。JMeter进程CPU使用率为50%，内存使用率为5%.
summary + 6544 in 00:00:19 = 348.5/s Avg: 273 Min: 50 Max: 501 Err: 0 (0.00%) Active: 100 Started: 100 Finished: 0
summary + 3456 in 00:00:14 = 252.6/s Avg: 277 Min: 50 Max: 501 Err: 0 (0.00%) Active: 0 Started: 100 Finished: 100
summary = 10000 in 00:00:32 = 308.1/s Avg: 274 Min: 50 Max: 501 Err: 0 (0.00%)
由测试结果可以看到Java扩展JMeter方式下执行时间，CPU、内存占用率比BeanShell方式下占明显的优势。读者需要注意的是Avg，Min和Max指的是“Dummy Sampler”的统计数据，两种使用方式下Dummy Sampler的执行时间都是一样的，而吞吐量后者比前者多了将近1倍，原因就在于测试步骤中的第一步的不同实现方式下，后者比前者快了很多。
使用建议##
BeanShell是JMeter内置的功能，但是由于它是脚本语言，动态加载执行的，因此效率不是很高，不太适合于在经常执行的场景下，比如将BeanShell放在循环内部，不断地被执行。比较适合的应用场景是放在执行一次、或者少数几次的地方，比如在循环外部读取配置文件内容等。
而Java扩展JMeter的实现方式的效率比较高，适合于放在经常执行的测试步骤中，但是由于它不是JMeter内置的功能，扩展起来需要有些工作量，而且部署的时候也比较麻烦（分布式运行的时候需要将自定义的JAR拷贝至所有的机器上）。读者根据自己的使用场景来选择适合自己的自定义脚本的方式。
关于我们##
XMeter成立于2016年，核心团队都来自于IBM，是一家领先技术的性能测试持续集成咨询与服务提供商。我们致力于提供给客户可靠,简单,低成本的性能测试解决方案。
