当我们使用JMeter / Response数据处理进行密集负载测试时，我们可能会非常小心我们选择的后处理器/脚本语言的类型。

在这篇文章中，我想说明这些后处理器/脚本语言如何影响测试的整体性能。

我们将比较以下后处理器和脚本语言。

• BeanShell PostProcessor
• BSF PostProcessor - Beanshell
• BSF PostProcessor - Javascript
• BSF PostProcessor - Groovy
• JSR223 PostProcessor - Beanshell
• JSR223 PostProcessor - Javascript
• JSR223 PostProcessor - Groovy

 

测试计划：

正如我们在所做的那样，  我们将使用一个简单的测试计划，没有任何外部依赖/定时器等，如下所示，准确地分析这些后处理器的性能。

我使用JMeter 3.0进行此测试。

所有Latency和ResponseTime模拟都已设置为0。

我们使用虚拟采样器来模拟硬编码响应。[对于响应数据，我将文档放在的文本中。它有超过56000个单词]。我们会做一个后处理器，在后处理器中，我们会使用这个分隔符“”将巨大的响应数据字符串拆分成一个数组。我们将迭代数组中的所有元素并调用toUpperCase（）方法。[我知道这听起来很愚蠢。这里的目的是做一些非常耗时的操作]。

线程组循环计数设置为1000。我们将重复此过程1000次并测量所需的时间。

Beanshell PostProcessor：

我在测试中添加了Beanshell后处理器，如下所示。我跑了测试。测试花了50秒才完成。

BSF PostProcessor - 语言：Beanshell

我删除了Beanshell后处理器并添加了BSF Post处理器并选择了Beanshell语言。我跑了测试。测试花了54秒完成。

BSF PostProcessor - 语言：Javascript

使用Javascript，测试大约需要  46秒才能完成。

 

BSF PostProcessor - 语言：Groovy

使用Groovy，测试大约需要  24秒才能完成。

JSR223 PostProcessor

我使用JSR223 PostProcessor对Beanshell，Javascript和Groovy等不同语言进行了相同的测试。

 

结论：

在重复相同的测试几次之后，我得到如此处所示的结果。

从上面的结果来看，与Beanshell和Javascript相比，Groovy似乎表现得更好。我之前总是使用Beanshell进行前/后处理。 我在此之后修改了我的测试以使用Groovy引擎。  如果您的测试计划在前/后处理活动中消耗更多时间，则您获得的性能结果不可靠。如果我们使用这种方法来测试应用程序性能，使用不同的处理器/脚本语言，我们将为应用程序提供完全不同的性能指标。为了更好地执行JMeter测试/更准确的性能指标，建议使用Groovy。