A thing of beauty!
You might want to know what exactly you were doing for the past few minutes. JMeter Users is a thread group, an element that controls the number of active virtual users and how many times they’re doing their job. Number of threads is basically the number of users (and note that for JMeter run with GUI, the limit is 300 separate threads, if you exceed this limit JMeter will crash). Ramp-up means how long it’ll take to load all the users – this setup means one user will be loaded every 3 seconds. Every user will perform the scenario 10 times, because you set it to 10 in loop count.
Next element: HTTP Request Defaults. Think of it as a form of global settings for HTTP Request ('home page' and 'changes' for example). The domain you set will be requested each time, so if you want to change it, you have to change it only in one spot. How convenient! Retrieve All Embedded Resources means that the user will download all the resources – fonts, images, stylesheets, just as a typical user would. There are two schools on whether you should use it or not, I prefer staying as close to the real user experience as possible. Using concurrent pool with an appropriate size is just as important, as it simulates how a browser would download those resources – in batches of 6, not one by one.
HTTP Requests are, simply put, steps your virtual users make. Changes element uses the domain address (google.com) with an extension specified as the Path (/imghp) – so that the virtual users visit google.com/imghp that is, Google Image Search page. If you need to simulate the users visiting more than one URL, insert more steps. To do so, just right click on the Changes element and select duplicate it. Rename it and change its path as you see fit.
After you start the test, you’ll see results pouring in in Graph Results. Take notice of the average throughput. That’s how many requests were sent per minute. See how it rises? That’s the ramp-up period. After the number of users stabilizes you can see how the remaining parameters behave – if you notice that over time the average response time (Average in the Graph Results) increases, it will mean that your server isn’t handling the load efficiently.
While Graph Results are very pretty, you will probably need more detailed data to record how the performance of the app changes. Luckily, JMeter has plenty of tools (called Listeners) for that! Feel free to experiment with all of them, though I’d recommend starting with View Results Tree. It provides all info you need to get to know what is wrong and debug the app.
- Know what your goal is – a scenario for a brutal spike on one page is an entirely different test than a steady, long-term heavy load.
- Always start small. The golden value is 250 threads per server's CPU core (for simple scenarios), but you should never start with it. Be gentle, never go over 50 in the first few runs, so that you don’t kill the server. Downtimes directly translate into lost money.
- Monitor the server from as many angles as you can during a load test, you never know where something might pop up. It’s good to have at hand a developer looking at the server console.
- Run the script a few times and compare the results, especially if you're running those on a working production server.
- Include as many types of user interaction as you can: from visiting paths to sending private messages, or checkout (if possible).
- Don’t stress test random servers you don’t own. It’s called Denial of Service (DoS) attack, and it’s illegal.
Now you are ready to test the performance of your app. Have fun!