标签：过程 硬编码 活动 tom href resize tar lan manual
当我们使用JMeter / Response数据处理进行密集负载测试时，我们可能会非常小心我们选择的后处理器/脚本语言的类型。
在这篇文章中，我想说明这些后处理器/脚本语言如何影响测试的整体性能。
我们将比较以下后处理器和脚本语言。
测试计划：
正如我们在这篇文章中所做的那样， 我们将使用一个简单的测试计划，没有任何外部依赖/定时器等，如下所示，准确地分析这些后处理器的性能。
我使用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。
标签：过程 硬编码 活动 tom href resize tar lan manual
原文地址：https://www.cnblogs.com/a00ium/p/10381271.html
