Mayday, mayday! Is that how you feel when looking over JMeter? No worries. On this particular May day (see how I did that?), we'll get you through your first JMeter script creation.
Apache JMeter is a great tool for doing performance testing of web-applications, but it may seem a tad bit tricky when looking it over for the first time. In this post we'll show you how to create your first Jmeter script from scratch.
The Test Plan, is the core element of the test script.
Look at the picture. Here we have two tables and three check-boxes. The first table, User Defined Variables
, allows us to set variables, which can be used in any other part of script, and this can be a great time saver when you move between testing environments and need to correct the Host IP (which happens a lot).
In this case you can simply set up this value as a variable and that's it: no problems with updating the script.
The second table is used, when, for example, you are going to create test-plan for databases and you need to make the JDBC driver visible for JMeter to get the SQL queries executed. In this case you need to add JDBC *.jar to this table, and JMeter will pick it up.
A few comments about check boxes-
Run Thread Groups consecutively.
If this option is checked, than all Thread Groups will be executed one by one. This may be useful in cases such as if the first Thread Group prepares test-data for a test, and the next one uses this set.
Run tearDown Thread Groups.
Some actions, like restoring the system after testing to a default state may be assigned to tearDownThreadGroups. We'll talk about them little bit later.
Functional Test Mode.
While JMeter is tool for performance testing, it also can be used for functional tests
because JMeter has a set of assertions and extractors (i.e. elements) which allow you to not only get the page from the server, but also to controll its content. In this mode JMeter saves much more information about each request (full response and request body). Obviously, such an approach consumes much more memory for processing data stream. That's why we generally don't use this option while using JMeter in non-single user mode.
Any JMeter test-plan should contain at least one Thread Group, which would then be the parent element for any test element (except Test Plan and Listeners). So, it will be the first element that we'll add to our test plan.
The first element we'll add to the Thread Group is the HTTP Request Defaults.
To quote, “this element lets you set default values that your HTTP Request controllers use. For example, if you are creating a Test Plan with 25 HTTP Request controllers and all of the requests are being sent to the same server, you could add a single HTTP Request Defaults element with the "Server Name or IP" field filled in. Then, when you add the 25 HTTP Request controllers, leave the "Server Name or IP" field empty. The controllers will inherit this field value from the HTTP Request Defaults element.”
In our example we are going to use the same URL for all requests. That's why this element, obviously, will be helpful for us. Let's add the site that we will stress test.
In general, JMeter works as browser-simulator. And to make this simulation more realistic, it has elements which can work with cookies and cache. These elements are HTTP Cookie Manager
and HTTP Cache Manager.
HTTP Cookie Manager.
This element is used for emulating browser's work with cookies.
HTTP Cache Manager.
This element is used for saving downloaded pages in cache during the first request, so they could be returned to Listener without downloading. This approach, obviously, has influence on test results.
One more important detail. Users never click links one by one, without any delay. Usually, there is a delay of seconds between thoughts, deciding whether to go or not to certain URL. That's why we need to emulate user think-time.
JMeter has a set of Timers, which allows users to set up a pause between different requests. In this example we will add Constant Timer to generate the delay for the fixed amount of time.
The last element we need is the View Results Tree.
Note, that this element is only needed during debugging tests. In general, View Results Tree is regards to memory consumption because it stores in memory all the results of requests. Obviously, if we use this element while we have many virtual users, we'll run out of memory and get a OutofMemoryException.
So remove or disable the View Results Tree (and wile you're at it, all other graphic listeners) before running your test.
Running a Load Test with BlazeMeter
Well, we've created a script. And, we're ready to run it in the cloud.
Assuming you already have your BlazeMeter account set up (if not, Sign up for free
), you can simply start by clicking Create Test -> 'Jmeter test'.