A pit about the Jmeter backend listener

       Jmeter's backend listener (BackendListener) is an asynchronous listener that can push data into the database, providing two options: InfluxDB and graphite. It is used to monitor the test results of the Jmeter sampler, and can display the test results in the form of trees, tables and graphs. In addition to listening to test results, most listeners also provide methods to view, save, and read saved test results. Specific usage reference: https://blog.csdn.net/smooth00/article/details/79926294

        However, in the process of use, there is a huge pit (also a small bug) in the Jmeter backend listener, which many people do not realize. That is, when multiple scripts are running in parallel, the monitoring data will be mixed together. Why is this? The following example is used to illustrate this problem:

We first create two scripts with different names, HRP-1.jmx and HRP-2.jmx. In order to distinguish the two scripts, the interface names are also different, as follows:

These two scripts each create their own backend listeners. The connected influxdb library is the same, but the application names are different, as follows:

Then run these two scripts at the same time, and it turns out that the data of the two scripts are all combined into one application (into the name of the first running script):

Looking at the influxdb database, it is found that the data generated by the two scripts are all classified under the Application Name of HRP-uplaod:

       Obviously, two different Application Names are named. Let's take a look at the configuration parameters of the back-end monitor. Even if the testTitle is changed to a different name, this problem will not be solved.

influxdbMetricsSender:org.apache.jmeter.visualizers.backend.influxdb.HttpMetricsSender
influxdbUrl:influx数据库的url。example : http://influxHost:8086/write?db=jmeter
application:被测试的应用名称。此值也作为名为“application”的标记存储在“events”中
measurement:使用默认的”jmeter“就行
summaryOnly:为true的情况下,只输出所有请求的集合数据报告,为flase的情况下,输出每条数据的详情报告、
samplersRegex:正则表达式将与样本名称匹配并发送到后端。默认匹配所有
testTitle:测试名称。默认的设置为 Test name。该值作为名为“text”的字段存储在“事件”度量中。 JMeter在测试的开始和结束时自动生成一个注释,其值以'started'和'ended'结尾
percentiles:要发送到后端的百分位数,多个值已;分割
TAG_WhatEverYouWant:自定义标签。您可以根据需要添加任意数量的自定义标签。对于它们中的每一个,只需创建一个新行并在其名称前加“TAG_”

So I debugged the source code of Jmeter, and found that the two scripts were started and run, and the following if judgment was different:

As shown in the above code, when the first script starts, listenerClientData = null, which can execute the following logic, but after the second script starts, the listenerClientData is not null, and the subsequent logic is no longer executed, which results in that the events table corresponding to the Application is not inserted. The corresponding data, that is to say only the HRP-upload is inserted:

The problem lies in the judgment of this listenerClientData, and we look at the variable myName and find that when the two scripts are executed, the "Backend Monitor" is displayed. There is no doubt that this is the default name of our BackendListener, indicating that this block uses This name is used to determine whether the listener is running. This is a bug. The names of the listeners of different scripts may be different or the same (the default must be the same). This is the name conflict that caused the monitoring data of the two scripts to be mixed. ! ! ! !

        I am speechless. There are only two ways now. Either change the source code of Jmeter, and change it to not use the listener name as the judgment condition, but the Application Name as the judgment condition. After the change, repackage it, just replace the one under jmeter The ApacheJMeter_components.jar package will do (more than 600 KB); the other way is to adapt to others by ourselves. When creating scripts, customize the BackendListener name instead of the default name (this can avoid this problem).

Let's change the names of the two listeners, one is called "backend listener-1" and the other is called "backend listener-2", run the two scripts again, and find that the monitored data is perfectly separated, as follows:

Looking at the influxdb library again, you can see that both sets of events have been stored, as follows:

The corresponding jmeter monitoring data are also two groups:

       At present, I am using Jmeter 5.1.1 version and have this problem. I believe that the previous version must also have this problem. The latest Jmeter5.3 source code also has this judgment problem. As for whether the subsequent version can solve it, I will pay attention. Even if we don't solve it, it will not affect us, as long as we know that there is this pit, we can avoid it in time.

Guess you like

Origin blog.csdn.net/smooth00/article/details/107558934