Encode base64 on the fly and shoot MongoDB from JMeter with BeanShell
I work in load testing for a relatively short time, and one of my main tools is Apache Jmeter . However, most of my colleagues did not use Beanshell in JMeter, and in this article I want to show a couple of ways how it can simplify and reduce the time for preparing for the tests themselves. And I'll show it on the example of text conversion to base64-encoding and simple firing in MongoDB.
This article is designed for those who already have some experience with JMeter, but did not use beanshell, so if you do not understand something, please do not hesitate to ask.
JMeter is a opensource load testing tool written in Java. It is easy to build your Samplers (objects that shoot) into it, but for this you need to open an IDE, inherit from the class from the JMeter packages, and write 4 methods. Export jar. And paste it. And for good you need to make a beautiful wrapper for this all, with buttons, checkboxes and all-all-all.
')
Okay, so what are beanshell and why is it needed? Beanshell is a java interpreter. Using beanshell you can write java-code immediately in JMeter, which will be executed during the test.
Using the interpreter, you should be aware of all the disadvantages and advantages of this approach. The main disadvantage is the performance of the interpreter. It will always be lower than the Sampler you compile. Of the benefits - the speed of development. You can always jot down a prototype of the sampler in beanshell, and when you’ll run into its performance, throw all the logic into a full-fledged sampler.
Moreover, in beanshell, you can write not only samplers, but pre-processors (perform actions before the shot), post-processors (perform actions after the shots) and listeners (receive reports on all shots of samplers / transactions).
It all sounds great, but why do many people know about JMeter, but so little about the interpreter? The whole problem in the documentation, namely its absence. On the wiki there is only one page with a description , and one with an example .
Imagine that we have two services that communicate with each other by transferring messages in base64 encoding. Our task is to load one of these services. We need to emit messages from one to another. Of course, we can immediately accumulate a base64-encoded data pool, but working with it, we, the testers, will be very uncomfortable. I would like to have a data pool in a meaningful, customary way for us, and that the information on the server is already in the necessary encoding. Moreover, situations are possible when we do not even have a pool of data. When the service itself gives us information, and we use it to send new requests.
We have a service (http://base64.nomanlab.org/?key=base64_key), to which we must pass the value as a GET parameter. I raised the service just for example. During the publication of the article, it will work, you can play around, but sincerely I ask, do not kill it, load testers =)
Let's first create our use-case test-plan. We add Thread Group, and in it HTTP Request. The test plan will look something like this.
The key (base64_key) is described separately, I used the User Defined Variables for an example and gave it the name key.
And the HTTP Request itself has this form.
But it is necessary for us that before a shot with the data in the cartridge something happened. Therefore, we select beanshell preprocessor and add it as a child to http request. And in it we write java-code. Java code? But how will he be connected with our patron? For this there are objects that link our test plan and the code in the interpreter.
Now we are replacing the key variable, so we need access to it. Its value for a given thread (thread) is stored in the vars object (which is something like a map).
Java code:
And here is the result:
Our key has been changed to a base64-encoded value. If we receive a response from the service in base64, and it needs to be parsed, we first use the post-processor Regular Expression Extractor to remove the message, and then we go through it using the same BeanShell post-processor. The code will be as follows:
And now for the sake of what all came here. Shooting in MongoDB. It is possible to use a similar method for loading MongoDB only in extreme cases when it is necessary to shoot at slow requests in order to understand their limit in Mong.
To shoot we need an object through which we will do it. We need an object with which we will manage the number of connections, their parameters. And before shooting, these connections need to be established, so the poets will share the logic of shooting and making connections. Installation will make in a separate ThreadGroup, which should start before the test. For this reason, choose setUp Thread Group. In it we set the options so that the semler is executed only 1 time and, of course, the BeanShell Sampler itself. And in it the following code:
Now we have objects through which we can shoot, it remains to make a sampler, which will simply use them.
The test plan looks like this:
I just shot at checking the status (DB.getStats (). Ok ()), and rested not at BeanShell, but at 1 Mong kernel, which I gave it to KVM on the local laptop.
Let's make a separate ThreadGroup and in it a BeanShell Sampler with this code:
And of course, beautiful graphics that show our performance.
At the end, 1 failure is visible, but this is due to the fact that I manually completed the test.
But with DB access, you can create a collection object (DBCollection) and play with it. It is possible inserts, it is possible cunning, maybe something else. You just need to know the Java API for MongoDB .
But in reality, to test Mongi, or any other database, it’s better to write your full-fledged sampler. I just wanted to show how you can do without them.
Download Base64 Test Plan
Download a test plan with Monga
Something like this, with simple actions, without getting into the IDE, you can do a lot of interesting things.
Foreword
This article is designed for those who already have some experience with JMeter, but did not use beanshell, so if you do not understand something, please do not hesitate to ask.
What is Beanshell and why is it needed?
JMeter is a opensource load testing tool written in Java. It is easy to build your Samplers (objects that shoot) into it, but for this you need to open an IDE, inherit from the class from the JMeter packages, and write 4 methods. Export jar. And paste it. And for good you need to make a beautiful wrapper for this all, with buttons, checkboxes and all-all-all.
')
Okay, so what are beanshell and why is it needed? Beanshell is a java interpreter. Using beanshell you can write java-code immediately in JMeter, which will be executed during the test.
Java? Interpreter? Load Testing? This is a joke?
Using the interpreter, you should be aware of all the disadvantages and advantages of this approach. The main disadvantage is the performance of the interpreter. It will always be lower than the Sampler you compile. Of the benefits - the speed of development. You can always jot down a prototype of the sampler in beanshell, and when you’ll run into its performance, throw all the logic into a full-fledged sampler.
Moreover, in beanshell, you can write not only samplers, but pre-processors (perform actions before the shot), post-processors (perform actions after the shots) and listeners (receive reports on all shots of samplers / transactions).
It all sounds great, but why do many people know about JMeter, but so little about the interpreter? The whole problem in the documentation, namely its absence. On the wiki there is only one page with a description , and one with an example .
Base64 example
Imagine that we have two services that communicate with each other by transferring messages in base64 encoding. Our task is to load one of these services. We need to emit messages from one to another. Of course, we can immediately accumulate a base64-encoded data pool, but working with it, we, the testers, will be very uncomfortable. I would like to have a data pool in a meaningful, customary way for us, and that the information on the server is already in the necessary encoding. Moreover, situations are possible when we do not even have a pool of data. When the service itself gives us information, and we use it to send new requests.
We have a service (http://base64.nomanlab.org/?key=base64_key), to which we must pass the value as a GET parameter. I raised the service just for example. During the publication of the article, it will work, you can play around, but sincerely I ask, do not kill it, load testers =)
Let's first create our use-case test-plan. We add Thread Group, and in it HTTP Request. The test plan will look something like this.
The key (base64_key) is described separately, I used the User Defined Variables for an example and gave it the name key.
And the HTTP Request itself has this form.
But it is necessary for us that before a shot with the data in the cartridge something happened. Therefore, we select beanshell preprocessor and add it as a child to http request. And in it we write java-code. Java code? But how will he be connected with our patron? For this there are objects that link our test plan and the code in the interpreter.
Now we are replacing the key variable, so we need access to it. Its value for a given thread (thread) is stored in the vars object (which is something like a map).
Java code:
// , Apache JMeter import org.apache.commons.codec.binary.Base64; // , / Base64 magicBox = new Base64(); // , String key = new String (magicBox.encodeBase64(vars.get("key").getBytes())); // vars.put("key", key); And here is the result:
Our key has been changed to a base64-encoded value. If we receive a response from the service in base64, and it needs to be parsed, we first use the post-processor Regular Expression Extractor to remove the message, and then we go through it using the same BeanShell post-processor. The code will be as follows:
// , Apache JMeter import org.apache.commons.codec.binary.Base64; // , / Base64 magicBox = new Base64(); // , String key = new String (magicBox.decodeBase64(vars.get("key").getBytes())); // vars.put("key", key); MongoDB Example
And now for the sake of what all came here. Shooting in MongoDB. It is possible to use a similar method for loading MongoDB only in extreme cases when it is necessary to shoot at slow requests in order to understand their limit in Mong.
Connection pool
To shoot we need an object through which we will do it. We need an object with which we will manage the number of connections, their parameters. And before shooting, these connections need to be established, so the poets will share the logic of shooting and making connections. Installation will make in a separate ThreadGroup, which should start before the test. For this reason, choose setUp Thread Group. In it we set the options so that the semler is executed only 1 time and, of course, the BeanShell Sampler itself. And in it the following code:
import com.mongodb.DB; import com.mongodb.Mongo; import com.mongodb.MongoOptions; import com.mongodb.ServerAddress; //bsh.shared beanshell bsh.shared.mongo = null; bsh.shared.mongoOptions = new MongoOptions(); bsh.shared.db = null; // bsh.shared.mongoOptions.autoConnectRetry = true; bsh.shared.mongoOptions.connectionsPerHost = 50; bsh.shared.mongoOptions.socketKeepAlive = true; bsh.shared.mongoOptions.socketTimeout = 10000; // precise-mongodb-amd64 bsh.shared.mongo = new Mongo(new ServerAddress("precise-mongodb-amd64", 27017), bsh.shared.mongoOptions); // test bsh.shared.db = bsh.shared.mongo.getDB("test"); if(bsh.shared.db.getStats().ok() == false) { System.err.println("MongoDB Connection error"); } Shoot !!
Now we have objects through which we can shoot, it remains to make a sampler, which will simply use them.
The test plan looks like this:
I just shot at checking the status (DB.getStats (). Ok ()), and rested not at BeanShell, but at 1 Mong kernel, which I gave it to KVM on the local laptop.
Let's make a separate ThreadGroup and in it a BeanShell Sampler with this code:
import com.mongodb.DB; if(bsh.shared.db.getStats().ok() == true) { IsSuccess = true; }else IsSuccess = false; And of course, beautiful graphics that show our performance.
At the end, 1 failure is visible, but this is due to the fact that I manually completed the test.
But with DB access, you can create a collection object (DBCollection) and play with it. It is possible inserts, it is possible cunning, maybe something else. You just need to know the Java API for MongoDB .
But in reality, to test Mongi, or any other database, it’s better to write your full-fledged sampler. I just wanted to show how you can do without them.
Files
Download Base64 Test Plan
Download a test plan with Monga
Epilogue
Something like this, with simple actions, without getting into the IDE, you can do a lot of interesting things.
Source: https://habr.com/ru/post/155297/
All Articles