%% Last Updated: - [[2021-04-12]] %% After you've [[JMeter Installation and Setup|installed JMeter]], go to the `/bin` directory where you installed JMeter and double-click either `jmeter.bat` (Windows) or just `jmeter` (Linux). The JMeter window will open with your very first project, and the only thing you’ll see is an empty Test Plan. In JMeter, you have to work a little bit to set everything up yourself before it's ready to go. When you open it up for the first time, all you'll have is a Test Plan. ## Setting up config elements The most basic JMeter load testing script will require these elements: - Thread Group - Transaction Controller - HTTP Request Sampler - View Results Tree Listener (or other listener) - Uniform Random Timer (or other timer) There are alternatives within JMeter for each of these, but for simplicity’s sake, I’ve included the most basic versions. To create a new config element, right click on the Test Plan and click Add > Config Element. ## Thread Groups In JMeter, a [[JMeter Thread Group|thread group]] is the name for a set of action a virtual user will carry out. Each thread group can be configured differently for execution. You can set how many threads (virtual users) each thread group will start and when, setting the ramp up and ramp down times, etc. For execution, it's best to have a stepping thread group, which comes with the Standard Set plugin, but for scripting, it's easiest to have just the normal thread group which will just run the script once. To create a thread group, right click on Test Plan > Add > Threads > Thread Group. You should get a child element under Test Plan that looks like this when you click on it:  These are the default values for a Thread Group. Some of these values need to be changed, which we’ll cover later. For now, let’s focus on getting a single user to hit one endpoint. ## [[JMeter Transaction Controller]]s A **Transaction Controller** is a way to organise a group of requests that logically belong together. This has reporting ramifications. For example, you might have 10 requests for resources for the same page. Rather than reporting on each of those separately, it might make more sense to report the total response time for the entire page. To add it, right click on Thread Group > Add > Logic Controller > Transaction Controller.  The only setting I would recommend changing is “Generate parent sample”. The Transaction Controller comes with this unticked by default, but I would tick it so that JMeter reports on the metrics for the transaction, not the individual requests. ## [[JMeter Samplers]] A "sample" is a request. If you choose to create a recording, these are built automatically for you. However, if you choose, you can also build it manually by creating a Sampler (right click > Add > Sampler > ex. HTTP Request). Samplers can contain HTTP calls, and they can also contain scripts to carry out (like the [[Beanshell]] Sampler). Click on the the HTTP Request Sampler and fill in the following fields:  In this example I’m just sending a GET request to [https://flooded.io](https://flooded.io/). ## [[JMeter Listeners]] To view results while we’re running the test, we’ll first need to add a listener. A listener captures requests sent, as well as their corresponding responses, for us to view later. There are quite a few listeners, but the most basic one that you’ll need is the **View Results Tree Listener.** It records all the details of the request and response pair and is best for debugging. Go ahead and right click on Test Plan > Add > Listener > View Results Tree. It will look pretty empty until we run a test, so let’s do that now. On the JMeter toolbar, you’ll see two buttons that look like a play button.  Click on the first one, the solid green play button. Now click on the View Results Tree listener. It may take a few seconds to get a response, but then your listener should look like this:  You’ll see that our request, “HTTP Request”, under the Transaction Controller, has been sent. By default, we’re on the Sampler result tab, which will show us some quick metrics about our request. Clicking on the Request and Response data tabs will allow us to see the raw request and response for that request as well. ## [[Variables in JMeter|Variables]] JMeter accepts variables in requests and most other fields. The standard format for a variable is `${variablename}`. Even parameter names and values are parsed for this format before the request is sent. Variables can also be created in the Test Plan level or via Add > Config Element > User Defined Variables. They can also be created by [[Beanshell]] scripts. Variables can be used in the path of results files in order to save timestamped results. One useful standard variable in JMeter is for timestamping. Here's an example: `${__time(YYYYMMdd_hhmmss)}` will give a timestamp in this format: `20140712_1320`. This is especially useful for time parameters passed in requests or for saving results. ## Timers The last basic element is the timer. For this tutorial, I’ve chosen the **Uniform Random Timer** because it’s easy to understand. A timer in JMeter is an artificially introduced delay. These delays space out the requests to make them more realistic— more on that later. For now, go ahead and add the timer by right clicking on Test Plan > Add > Timer > Uniform Random Timer.  Enter values in the Thread Delay Properties. A good place to start is by having a Constant Delay Offset of 10,000 ms and a Random Delay Maximum of 1,000 ms. This means that the delay will be at least 10,000 ms long, plus a variable amount of up ot 1,000 ms. JMeter automatically removes timers when calculating the response time. ## Execution Now let’s click on that second green play button on the toolbar.  The first green play button runs the script including the timers, and the second one runs the script without any timers. For the most part, while we’re scripting and running just one user, we’ll want to use the second play button to save a little bit of time. Go ahead and play around with those now. Regardless of which one you use, the response time JMeter reports in the View Results Tree Listener will be the actual response time of the request, not including the timer delays. Another thing to note is that timers are always applied before the requests, not after them. If you’ve been following along, your test plan should look like this:  One final note about elements in JMeter: where you put the element matters. For example, since we put the timer as a child of the Test Plan, we’re applying the timer to all samplers in that context. If we wanted to apply it only to one HTTP request, we’d need to put it as a child element of that HTTP Request Sampler.