CAUTION! Blazemeter now predominantly runs on the V4 ("Version 4") architecture, whereas the legacy V3 ("Version 3") architecture has been deprecated and is no longer supported. This and other legacy articles apply to V3 tests for customers who have not yet fully migrated to V4. For more details about the current V4 testing architecture, please begin with our guide, Benefits & Advantages of Blazemeter's New Infrastructure & UI.
JMeter is an open source load testing tool that enables you to execute performance tests on your app or website. To run a load test, you need to create a script that will detail the steps of your testing scenario, and then run it. You can either run it on your local machine through JMeter or in the cloud through BlazeMeter. This article will take you through an overview of all these options.
Step 1: Write Your Script
There are various ways to create your script:
- Use the BlazeMeter Chrome Extension to record your scenario. This is the simplest way.
- Use the JMeter HTTP(S) Test Script Recorder. This sets up a proxy that you can run your test through and record everything.
- Go manually all-the-way and construct everything from scratch. This is more common for functionality/QA tests.
If you get your script from a recording (as in steps 1 & 2), keep in mind that:
- You'll need to change certain parameters, such as the Username & Password, or you might want to set a CSV file with these values so each user can be unique.
- You might need to extract elements such as Token-String, Form-Build-Id, and others by using Regular Expressions, the JSON Extractor or the XPath Extractor. This will enable you to complete requests like "AddToCart", "Login" and more. See this article for more information about these procedures.
- You should keep your script parameterized and use configuration elements like HTTP Requests Defaults to make your life easier when switching between environments.
Step 2: Testing Locally With JMeter
Start debugging your script with one thread and one iteration, by using the View Results Tree element, the Debug Sampler, and the Dummy Sampler. Keep the Log Viewer open in case any JMeter errors are reported.
Go over the True and False responses of all the scenarios to make sure the script is performing as you expect.
After the script has run successfully using one thread, raise the number to 20 threads for ten minutes and check:
- Are the users coming up as unique (if this was your intention)?
- Are you getting any errors?
- If you're running a registration process, take a look at your backend - are the accounts created according to your template? Are they unique?
- Analyze the statistics in the summary report - do they make sense (in terms of average response time, errors, hits/s)?
Once your script is ready:
- Clean it up by removing any Debug/Dummy Samplers and deleting your script listeners.
- If you used Listeners (such as "Save Responses to a file"), make sure you don't use any Paths! If it's a Listener or a 'CSV Data Set Config' make sure you don't use the path you've used locally and use only the filename instead (as if it were in the same folder as your script)
- If you're using your own proprietary JAR file(s), upload them to BlazeMeter along with the JMX.
- If you're using more than one Thread Group (or not the standard one) - set the values before uploading them to BlazeMeter, and make sure to uncheck the 'Threads' and 'Users' scrollers in BlazeMeter's test configuration page so the values will be pulled from the Thread Groups.
Step 3: Uploading your JMX and the tests assets
You can start creating your JMeter test by clicking on the Performance section, then the "Create Test" button on the top navigation bar and then select the JMeter Test. Do not forget to create the test within the relevant Project.
On the top left section of the screen, you'll find a central location to upload the JMX.
- All the files in your account are downloaded to the remote JMeter servers at the beginning of each test.
- During the test, the files in your account are synchronized every few minutes.
- You cannot delete files during the load test. Files can be deleted only once the test has ended or before it has started.
If you require more information regarding uploading files to the test configuration page, please refer to this article.
Under the 'Load Scenario Properties' section, you have the option to select the Location that you want your test to be run in.
You can control and override Jmeter's configuration by moving the markers along with the sliders. Heres a quick explanation of each one:
- Users. Select the number of users you want. The engines and thread are adjusted automatically according to this number.
- Engines and Threads: If you don't want these to be set automatically, you can manually set them by unchecking the Users section. Note: Free-tier users don't have access to engines and are limited to 50 threads.
- Ramp Up: Select how fast you want the test to ramp up.
- Iterations: Select the number of iterations in the test. Note: this is automatically set to infinite
- Duration: Set the full-time duration that you want the test to run
- Delay: Set the duration of the delay between each page request.
- Limit RPS: Set the number of Requests per second you do not wish to go over.
Now that you've set up your test, you can choose to receive an 'Email on report end'.
All done? Now just give it a name, click save and you're JMeter test is ready to go!
Advanced Options
- Jmeter version - Choose the JMeter version you would like to run the test on. While this is your choice to make, we strongly advise on choosing the latest JMeter release.
- Java version - Choose the JAVA version you would like to run the test on - 1.7 or 1.8.
- Test Failure Criteria: Set failure criteria for various metrics in order to fail the test if needed.
- DNS - Hostname Override: Use this if you want to tell the JMeter engine not to automatically go to the DNS, but to use a specific IP record instead. Just enter the appropriate IP and redirect your script without changing your labels. If you have a JMeter script (which will be explained later in this document), you don't need to change your script in order to redirect the load between your staging and your production environments.
- JMeter Properties - Here you can set your JMeter parameters. This is a real-time feature. e.g, you may want to add hits and give it the value 100 - or maybe type in execute - true. These parameters will be sent to the engine while running the script.
- Command Line Arguments - Here you can send command line variables straight to the Console or engine properties files. e.g, if you want to send something to the JMeter properties file, you can do it from here. Just bear in mind that you're overriding parameters here so if you make a mistake, it could ruin your test! So use this with caution.
- Network Emulation: Here you can select any kind of preset to emulate your network connection (mobile or web), the bandwidth and latency.
- New Relic APM: Just enter your New Relic API key here and you'll be able to select profiles.
- New Relic Insights: Enter your credentials to access New Relic Insights.
- Cloudwatch: Integrate your AWS application monitoring tool and you'll be able to select profiles and view your Application server's side KPIs.
- There is one additional feature here - the Split CSV.
- Dynatrace APM: Integrate your Dynatrace APM agent with the BlazeMeter test in order to send metrics to the on-premise Dynatrace application.
- AppDynamics APM: Integrate your AppDynamics APM profiles with BlazeMeter's tests.
You can upload a CSV in the same place that you upload your JMeter scripts (make sure that you remove the path from the CSV data set configuration controller as the files will share the same folder). If you do this and you have more than one engine, you probably won't want two engines to execute the same login for the same user. So here you can check the Split CSV option, and the users will be sent randomly to the engines (i.e. line one will go to engine one, line two to engine two, line three to engine one, etc.)
For more information on using CSV file in your test, please refer to this article.
Once again, Make sure you name your test, save it and you're ready to go! Great! You've now successfully set up your JMeter test. Ready to move on to the next step? Read our article on Running BlazeMeter Tests to find out how.
Sandbox Testing
The SandBox is actually a test which has up to 20 users, using 0 engines and runs for up to 20 minutes.
The SandBox configuration allows you to test your script and backend and ensure everything works well logically.
Here are some common issues you might come across:
- Firewall - make sure your environment is open to the BlazeMeter CIDR list and whitelist them.
- Make sure all of your test files e.g: CSVs, JAR, JSON, User.properties, etc. are present.
- Make sure you didn't use any paths.
If you're still having trouble, look at the logs for errors (you should be able to download the entire log).
A SandBox configuration can be:
- Engines: Console only (1 console, 0 engines)
- Threads: 1-20
- Ramp-up: 0-1200 seconds.
- Iteration: Test continues forever
- Duration: 1-20 minutes
This will allow you to get enough data during your ramp-up period to analyze the results and ensure the script was executed as you expected.
Want to learn more about running JMeter tests from BlazeMeter? Watch our on-demand recording, How to Make JMeter Highly Scalable and More Collaborative With BlazeMeter.
0 Comments