JMeter tricks

2023-06-09

JMeter is an Open Source tool for load generation. It support multiple protocols and technologies, but is probably most used to generate traffic over HTTP and HTTPS for load tests, stress tests, and performance analysises.

If you are used to the performance testing tools of major vendors the approach of JMeter will strike you as a bit cumbersome, but hey; it's free and competent once you gotten the hang of it.

The first times I used JMeter I found it hard to use, but the more I got the hang of it the more I apprechiate the tool.

Installing JMeter and getting it to run

It's easy to install JMeter. Download the installation archive from Apache JMeter. Unzip and place all the folders in the same catalogue and double click the jmeter.bat file and you should get the GUI started.

Hints and troubleshooting►

There are a few things that could go wrong that you probably should double check right away:

  • Having a Java JRE installed is a pre-requisite for running JMeter.
  • On Linux you might have to chmod the files to get them executable.
  • Starting with Run as admin could be nesesary on heavily locked down machines.
  • If your machine wide Java settings are wrong you will get troubles if you intend to use the more advanced KeyStores configurations.
  • If your have a corporate proxy to work with you probably want to create a specific bat file referencing the jmeter.bat -H proxyHostName -P proxyPort and possibly proxy login information. This will be needed for recordings to work, and (depending on systems settings and protocol) even for script execution.
  • I've seen some inexperienced JMeter users create a HTTP(S) Sample for the landing page URL, increase the number of threads, running the scripts and then be amazed that the respnse times are great. They are right, but the load they apply is not near the realistic load. JMeter need each request stated explicitly (every javascript, every CSS, and every image). That's why the preffered way is doing a recording, as below.

Fastest approach - recording a HTTP request sequence to multiply

We need to do some configuration for first run with JMeter recorder. Almost all of these steps are only needed for the very first recording since the certificate is already installed and your browser probably has stored your alternative LAN/proxy settings for easy access.

Set up somewhere to store recorded HTTP(S) transactions

We need somewhere where the recorded transactions end up, not to confuse them with other stuff in our JMeter Test Plan. It's almost always a good idea to create a specific Thread Group for each time we record transactions.

  1. Start JMeter by invoking the jmeter.bat of the bin folder. You should soon see the JMeter GUI.
  2. Right-click Test Plan in the left pane to choose Add->Threads (Users)->Thread Group.
  3. Right-click the new Thread Group and choose Add->Logic controllers->Recording controller.

    Soon we'll setup this Recording Controler to be the target for recorded transactions.

Set up the Recorder for first use

JMeter records transactions by the use of a pass-through proxy mechanism. The recording proxy listens on a IP port of your choice and evaluates the traffic passing through it for recording.

  1. Right-click Test Plan in left pane to choose Add->Non-test elements->HTTP(S) Script recorder.

    This element is the one we'll use for recording.
  2. Focus the new HTTP(S) Script recorder element in the Test Plan tree view by clicking it.
    In the right pane: Make a note of the port number (defaults to 8888).
  3. Choose a specific Recoring target by choosing the Thread Group->Recording Controler you created in previous step.

Setup your web browser to tunnel traffic through the JMeter recording proxy

To be able to intercept the transactions from the web browser we need to configure the traffic from the web browser to be tunneled through the JMeter Script Recorder. This is done by re-configuring the web browser to use the JMeter proxy. If you are behind a corporate proxy you might need to review the hints above.

  1. Re-configure your web browser proxy settings to tunnel the communication through the recording proxy (localhost/127.0.0.1 port 8888, or whatever port you set in the step above).

Configure a local SSL certificate to enable HTTPS

Most web sites uses HTTPS rather than HTTP for security reasons. When JMeter intercepts HTTPS traffic it need the JMeter recording proxy to appear as a web server to the web browser, hence needing to terminate the SSL and reconnecting with SSL, but with its own certificate. This temporary certificate is created at first run, but the web browser need to be configured to accept the certifcate as a trusted one.

  1. In JMeter, click the HTTP(S) Test Script Recorder and click the Start button.
  2. If it's the first time you are running the HTTP(S) Test Script Recorder a certificate is now created in the jmeter/bin folder. It has a name with the phrase temporary in it and only has a life span of a few days. For script setups you expect to take longer there is a setting in one of the properties files in the jmeter/bin folder to adjust the life span of this certificate - or simply remove it and JMeter will create a new one upon next run.
  3. Install the certificate in the web browser (Settings->Certificates->Import). Don't forget to check the checkbox for Use this certificate to identify web sites.

Record your script

When we record a script all HTTP related transactions are passed through the proxy, but there are a lot of settings to be made to limit the appeared complexity.

  1. Perform your test sequence in the web browser. Note that the resources appear in the Recording Controller in JMeter.
  2. Click the Stop button in the JMeter recording popup window.

Restore your browser

This optional step is sometimes forgotten, and sometimes it's frustrating to troubleshoot your Internet connection for a while before remembering you've changed your browser connection settings. It's good practice to reset it immediately to avoid this confusion.

  1. Set your browser proxy settings back to their initial settings so you don't forget that later.

Hints►

Recording scripts could be messy and time consuming. There are a wide range of things you could do to make it easier:

  • In your recorder you could set the recorder to ignore some type of content from being recorded. This is generally not affecting the load that much (atleast given any system where users frequently return so their cache is utilized) since much static content is being cached anyway. My general exclusion pattern looks like this: (?i).*.(bmp|css|js|gif|ico|jpe?g|png|swf|woff|woff2).*. This pattern excludes a wide range of different types of images, fonts, scripts, and styling information.

    I sometimes even include the annoying Firefox check for update request often being recorded.
  • In the recording dialogue of HTTP(S) Test Script Recorder there is a field called prefix. I tend to use this for grouping and ordering the transactions. This is done by assigning a prefix before any interaction with a page, for example giving the first interaction the prefix 0_Nav_to_landingpage, the second one 1_Click_login_button and so forth. This will help you identify what is happening in the long list of transactions in the recording controler while you work with it for parameterization or correlation.
  • When starting the HTTP(S) Test Script Recorder you could choose to group the recorded samples. Try this out. It's useful for reducing complexity.
  • Use Firefox for recording. The networks settings of Firefox could easily be set independenly of the system proxy settings used for example by Edge.
  • Empty web browser cache prior to recording to avoid differences for playback.
  • If you get certificate problems, and haven't added any other certificate than the temporary one provided by JMeter - just delete this certificate from the
  • Any Thread Group or other element may be renamed for clarity. This is a really nice feature.

Parameterizing and correlation

The tricky part of preparing load tests is always making sure the transactions run smoothly. You could parameterize for example login information, or correlate session ids from any response to be used in sub-sequent requests.

JMeter has some really good features for correlation and parameterization, for example the possibility to search through all transactions for specific strings, even with regular expressions matching.

Beware: Many web sites send HTTP status code 200 even upon errors, so check the response body in the Result Tree, or add a general (at Test Plan level) Response Assertion for response not containing the word error or any other warning notice you could think of. You may disable or remove this assertion when happy with the script.

Hints►

It could be tricky to do all correlations correct, but don't give up. There's a few tricks you could utilize:

  • Using the CSV Data Set Config is what's needed for linked data sources (e.g. user name/password).
  • Include a Debug Sampler in your Test plan. With this sampler you could check the state of each variable after any transaction in the script execution (Test result tree)
  • Name your variables cleverly so they are easy to search, and give them the default value of VAR_ERROR so you may search easily for failing correlations.

    Also, variables follow Java restrictions. You cannot name variables with numbers first in the variable name.
  • Include a Cookie manager in your Test plan to be able to forget about cookies.

Load configuration

Load generation in JMeter is done through using different Thread groups for different load behaviours, and then combining these with Think Time elements.

There are a range of different type of think times. Read up on them and use the one you favor.

Script execution

You should not execute scripts for a load test from the GUI of JMeter, but you could use the GUI to test your scripts wile developing them. Use the command line instead for when it's time for proper load tests. Check the arguments and run.

  1. In JMeter, click the Thread Group and set your desired number of concurrent users (Number of Threads) and the ramp-up time.
  2. Right-click your Thread Group and add some listeners to view results:
    • Add->Listeners->Summary Report
    • Add->Listeners->View Results Tree
    • Add->Listeners->Response Time Graph
  3. Save your Test Plan and press the Play button in JMeter ribbon menu to start execute your test.
  4. Monitor your test while it is running by clicking the different listeners.
  5. Don't forget to check that your load generator isn't the bottleneck. Check both the RAM/CPU/IO utilization, but also JRE usage since a JRE won't use more than it's given memory.
screenshot

Advanced usage►

Plugins to JMeter

Check out the Plugins of JMeter. You could access the plugin functionality directly from the menu.

Increase memory for JRE to enable more users

You could increase the memory space for JMeter. This could be useful if you have very complex scripts.

Don't quit to quickly

I've noticed that if you have large Test Plans and quit the GUI to quickly after pressing the Save button, the save file get truncated. This calls for unnessesary rework.

Use controler and load agent architecture

The JMeter enables a Controler and LoadAgent patterns, meaning you may distribute load over several different machine that generate the load. This could be done both for comparison between sites, but also as a mean to produce really large loads, or to get around load balancing with IP sticky sessions.