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.

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:

1. Firewall - make sure your environment is open to the BlazeMeter CIDR list and whitelist them.
2. Make sure all of your test files e.g: CSVs, JAR, JSON, User.properties, etc. are present.
3. 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.