User Guides

Please take a moment to view our movie – JMeter in the Cloud, a cloud-testing platform by CloudIntelligence.

This document assumes you are already familiar with JMeter and you have pre-existing test-scripts you want to use. If so, you can start your load immediately without a setup fee.

If you are new to JMeter we suggest learning more about how to use JMeter.

Before launching a test in the cloud you’ll need to follow these three easy steps.

1. Open an account at cloud-intelligence.com
2. Purchase computing-hour credits
3. Make sure your computer and browser meet the minimum requirements to run JMeter in the Cloud.

Follow this link to request an account at cloud-intelligence.com.

Bellow are additional prerequisites you will need in place before launching a test. Please visit our FAQ section to see how you can make sure that all prerequisites are in place.

Make sure Java & Javascript are enabled

In order to connect to the remote server and allow access to the remote JMeter console we use a remote desktop application by NOMACHINE. This remote desktop application uses a Java Applet. Please follow these instructions to make sure that all of these parts will operate normally during your test.

1. Java installation is required for the remote connection application. You can download it from http://www.java.com/en/.

1. Javascript must be enabled. Check under Internet Options => Security to make sure Javascript is enabled.

Outbound port 22 is open

We use SSH (port 22) to communicate with the remote servers, please verify that outbound port 22 is open.

Please visit our FAQ section to see how you can make sure that all prerequisites are in place.

Buy computing hours credits

After you have created an account at cloud-intelligence.com you will be required to purchase credits before running any tests. Use Buy Credits on the right hand menu to make your purchase. Once approved, these credits will appear in your account.

If you are using any of our cloud-testing services through one of our partners, you should use the Request Credits on the right hand menu to request more credits.

In order to run tests you will always need to have a positive credits balance.

You can choose to create your test-script on your local machine by downloading and using Apache JMeter or create your test-script in the cloud environment.

You can login to your account on cloud-intelligence.com, after you have created your JMeter test-script. Then use the Add Test menu function to create a new test. Follow the instructions on the page to complete the required details.

You need to choose the number of JMeterEngine(s) that will participate in the test. We recommend running up to 300 threads/virtual users per one JMeterEngine if you are using HTTP/S protocol. If you are using any other protocols such as Web Services we recommend up to 70 threads/virtual users. The number of supported threads depends on your script intensity and available resources. The more intense your script – the less threads a single JMeterEngine can support.

You can optionally fill the command line arguments. For example, if you upload a file named: my_config.jmx, the command line argument should include: -t my_config.jmx. Please make sure this file is uploaded to your account using the Files tab (see instructions below).

You can choose the specific geographic location from which you wish to run your load. This selection can be modified before each run, that way you can run the same test several times and each time choose a different location in the world. We provide four global locations, two in the US, and one in Europe and one in Asia.

Don't forget to save your test.

Use the Files tab to upload your test-script (a file that ends with JMX extension). Upload any other files you wish to use during the load test.

The Files tab will appear only after you save the test for the first time.

At this point:

• The Files tab is accessible at all times. You can use it to upload, download and delete files.
• All files in your account are downloaded to the remote JMeter servers at the beginning of each test.
• During the test, 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.
• Prior to terminating your test session please make sure all files are synchronized.

Limitations on File Names

• File names should include only alphanumeric characters, underscores or hyphens: [0-9],[aA-zZ],[_-].
• File names should always include an extension.

For example:

1. A file name: "my_file_no_4.csv" - is good.
2. A file name: "m$ file &" - is bad.

Affecting Speed of the Test

Not including files archived in the "zipped" folder, all other files are being downloaded to all of the remote servers each and every time a test starts.

A test will not start and the JMeter console will not be accessible before all of the files are downloaded.

For example, if the Files tab contains numerous large files, it can take few minutes for them to download and the test can not start prior.

Therefore, we recommend not to have files that are not in use with-in the Files tab. It is best to clean this tab prior to launching a test.

In the Add/Edit Test page, you can change the advanced default configuration in “Advanced Test Properties” section to fit your specic needs.

Extended JMeterEngine Resources Configuration

The JMeter in the Cloud default configuration includes running a single JMeter console on a dedicated server coupled with additional servers running two JMeterEngine(s) each. As each server is equipped with a dual core CPU and 1.7GB of memory, we limit the memory available for the console to 1GB and for each JMeterEngine to 512MB. In most cases this configuration should be more than enough. That being said, some scripts can require more resources than others.

For the purpose of more intensive scripts we provide an extended resources configuration. With this configuration each JMeterEngine runs on a dedicated server. The memory available for the JMeterEngine is limited to 1.5GB, triple the amount provided by the default configuration. Because this configuration uses one server for each JMeterEngine it requires additional computing hours when compared with the default configuration.

JMeter Version

While you can choose to use JMeter version 2.3.4, please note that by default JMeter version 2.3.2 is selected. You should use the JMeter version you are using on your local computer to create your test scripts.

Slow Internet Connection

Enable this check box only if you are using a low bandwidth Internet connection. In any case we highly recommend using JMeter in the Cloud with a strong Internet connection only. We recommend not using JMeter in the Cloud on a virtual desktop (for example using CITRIX). We are providing a remote application access to the remote JMeter servers. This requires a strong bandwidth Internet connection.

Dedicated IPs

In some situations, such as a when you are connecting from behind a corporate Firewall, you would want the JMeterEngines to have dedicated IPs. We can assign dedicated IPs to the JMeterEngines. Dedicated IPs are an expensive resource. If you wish to have dedicated IPs assigned to you, please contact us.

JMeter user & system properties

In case you need to add properties to JMeter’s default “user.properties” file, go to the Files tab of the relevant test and upload your “user.properties” file. JMeter in the Cloud will identify it and will add it to the JMeterEngines and console servers. Similarly, "system.properties" can be uploaded to update system properties.

New jar files

Users that develop and/or enhance their JMeter components can upload their own JMeter components and add-ons.
To do this, jar your JMeter components and then upload the jar files. JMeter in the Cloud will identify the uploaded jar files and will automatically copy them to the JMETER_HOME/lib/ext directiry. 

System hosts file

You can control the “hosts” file of the launched servers. As a result, you are able to add additional local DNS entries as if you were editing the hosts file locally. One important use for this feature is to provide permanent DNS resolution for certain DNS names. This can reduce the number of times JMeter in the Cloud calls on your DNS for name resolution.
To do this, upload your “hosts.txt” file. This file will replace the "/etc/hosts"  file on every launched server. Please note that the new hosts file should include at least one line of the form: 127.0.0.1 localhost. The name of the file must be "hosts.txt". The file must be uploaded prior to launching the servers. Any "hosts.txt" file uploaded during the test requires servers reboot for it to take effect.

To launch all servers related to a test, use the Launch Servers menu function on the right hand side. Clicking the Launch Servers link will launch a reservation of servers in the cloud. The status of this operation appears in the status area on the middle of the page. Launching a reservation can take up to three minutes. If you are using dedicated IPs, it can take up to five minutes.

The servers are launched and their status will be automatically updated. Wait to be notified that all servers are ready to run.

Once all servers are launched an applet will appear allowing access to the remote JMeter console through the NOMACHINE remote connection application.

In case Java is not installed on your local machine, you will be asked to install it. Click here to download Java and follow the Java installation wizard

The NOMACHINE confirmation pop-up will be displayed. NOMACHINE is the remote connection application through which JMeter console is displayed on your local machine. Please check the “Always trust content from this publisher” option and click on the Run button.

If this is the first time you launch a test, the NOMACHINE applet will install a small component on your PC that will enable the remote session. This process can take up to two minutes for the first time.

Click the Continue button in order to start the remote connection session.

Wait for the wizard to finish the setup process.

Click on Yes in order to approve the connection with the remote servers in the cloud.

Wait for the JMeter log and console windows to open, your previously uploaded test-script is available for you to run as if you were working from your local machine.

Once servers are launched and the applet appears, click on Continue button in order to start the remote connection session.

You can see the applet establishing the remote connection. Please wait for this process to complete.

Click on Yes in order to approve the connection with the remote servers in the cloud.

Once the JMeter console window is open, your previously uploaded test-script is available for you to run. Please note that you can change the script and save the changes through the remote JMeter console, the changes also affect the JMeter file you can download from the test page.

You can choose to run your load on all servers simultaneously or start each JMeterEngine separately. We recommend running no more than 300 concurrent threads for each JMeterEngine.
In order to run all servers simultaneously, click on the "Remote Start All" option under the “Run” menu:

In order to start each JMeterEngine separately, select "Remote Start" option under the “Run” menu. All available JMeterEngines are listed; click on the one you want to start:

You can also run the load on the JMeter console by clicking on the “Start” option under the “Run” menu. This is the same as running another JMeterEngine.

Please note that we do not recommend running a load on the JMeter Console. This is because it is already consuming massive amounts of CPU capacity for calculations related to aggregating remote JMeterEngines results. Doing so may cause the JMeter Console to freeze.

The same can be done for stopping the load (by choosing “Remote Stop All”, selecting a JMeterEngine from "Remote Stop" list or clicking on “Stop” option).

JTL files are an inherent functionality of JMeter. You can read more about JTL files in the JMeter user guide. With this functionality you are able to have real-time reports including detailed graphs of tests results.

In order to view real-time reports, all you need to do is specify a JTL file name in one of JMeter's listeners. For example, add "Aggregate Report" listener and specify a JTL file name. Make sure the file ends with the extension: "jtl". Also, please make sure that the JTL file is saved as XML and not CSV. Once the test is running, you can view/download the JTL file itself and the resulting reports using the JTLs and/or Files tabs.

All graphs are displayed in the JTLs tab, click on the graph’s thumbnail in order to see it. Refresh the page in order to see the updated graph.

You can press on the graph to download the image and include it in your report. Clicking on the JTLs tab generates all available reports. Make sure you press this tab at least once before terminating your test session in order for the graphs to be generated. Please note that these reports will also be available for download after terminating the reservation in the Files tab, under the Zipped folder.

How to Ignore Rquests in the Reports

If your report includes unwanted labels such as PNGs, JPGs, CSSs etc, you can order the report not to include these labels simply by adding the word "ignore" to the label.

Any label with the word "ignore" in it will not be presented in the report.

That said, all measures of this request will appear as part of the statistics.

Available Graphs

To see an example of a live reports screen, please visit our demo section.

There are two types of reports:

1. Aggregated Reports
2. Detailed Reports

Aggregated Reports

Aggregated reports present various distributions of response times, latencies and errors throughout the entire test. These reports can draw the entire picture in a single snapshot.

Aggregated Reports include:

1. Two graphs: Response time distribution by percentage from the entire test and  according to the number of samples
2. Two graphs: Latency distribution by percentage from the entire test and  according to the number of samples
3. Two graphs: Error/Response Code distribution by percentage from the entire test and  according to the number of samples

Detailed Reports

Detailed reports present the average value of each measure per minute throughout the entire test. Measures include:

1. Response time
2. Latency
3. Hits per minute
4. Number of concurrent users (Active Threads)
5. Errors

There is one view for all URLs that were included in the test and detailed views for each unique URL.

Detailed reports include:

1. Response Time and Latency Vs Users (Generating this graph requires a user action. Please read our FAQ section for further details)
2. Response Time and Latency Vs Hits
3. Response Time and Latency Vs Errors
4. Hits Vs Users (Generating this graph requires a user action. Please read our FAQ section for further details)
5. Hits Vs Errors

To see an example of a live reports screen, please visit our demo section.

Most of these reports are available only through JMeter in the Cloud and not through the regular JMeter interface.

Although JMeter does support few graphic reports through the regular interface it is not recommended to enable them as they consume a lot of memory and will result in the console freezing under heavy load. Use the above mentioned reports instead. They have no affect on JMeter during the test run and are accessible after the test had ended.

Generating "Users vs Load Time Average" report requires the following specific actions:

1. Using the JMeter Console, add a "Config Element -> User Defined Variables" .

1. Add a variable named: "in". This variable's value should be the following: "${__P(InstanceID)}".

These actions allow the identification of each individual JMeterEngine. If these actions are not performed the graph will show the maximum users per one JMeterEngine. For example, assuming there are 4 JMeterEngines, each running 50 users. Without these specific actions, the maximum number of users will show 50. With these actions performed, the maximum number of users will reach 200.

Log Files

CloudIntelligence enables you to monitor each JMeterEngine log and each server CPU and Network bandwidth performance logs. These are available in the Logs tab. Click on the requested tab name to display the relevant information. The logs are automatically refreshed every 30 seconds.

Through the Logs tab you can view the last added lines of each log file. You can further download or view the entire file. Large log files (over 10 MB) are not displayed. You can only download a large log file.

We highly recommend to monitor the logs at the beginning and during the test. Any problem or error will appear in the log files.

Network Information

In addition, you can view all public DNS names involved in the test session in the Network Information tab. This can be used to configure your firewall to allow access from the specified domain names. Please note that each test session uses different domain names:

Availability

Please note that these files will also be available for download after terminating the reservation in the Files page, under the Zipped folder.

If you wish to save and download the table load results displayed in JMeter GUI, click on the Save Table Data button at the bottom of the results view. In the pop-up that opens, save the results in a csv file under the default JMeter folder. The file name must NOT contain spaces.

The results file is now saved in cloudIntelligence website, in your test page Files tab where it is available for download

The file is also available for download after terminating the test, from the Files tab.

It is very easy to use "CSV Data Set Config" in the cloud. Upload your CSV files using the Files tab.

In the "Filename:" field in the "CSV Data Set Config" use only the file name without any path. If you are using existing script you have created in your local machine, do not forget to erase the local path.

For further information about how to use "CSV Data Set Config" with JMeter follow this link.

If you want to use multiple JMeterEngines with a different CSV file per JMeterEngine, you will need to upload a different file for each JMeterEngines and use a parameter to differentiate each file.

Each JMeterEngine uses a distinct parameter ${__P(InstanceID)}. Please note that the "InstanceID" values start from 1 for the JMeterEngines. The value of "InstanceID" for the JMeter console is 0.

In the example above, incase you are using two JMeterEngine(s), you can upload files named file1.csv and file2.csv. In the "Filename" field you should specify: file${__P(InstanceID)}.csv.

The first JMeter engine will read file1.csv. The second will read file2.csv.

If this information is not sufficient, please contact our support.

The "Terminate all but Console" is a special option that allows you to manage reports and results without having to pay for the servers' time other than on the Console.

By using this option you will terminate all of the load servers, but keep the GUI console open. In this case all load servers are terminated, but the load results, logs and graphs are still available for viewing and downloading from the CloudIntelligence website.

You are only billed according to consumed computing hours. Once you terminate all load servers but the Console's, you are billed only for the Console time.

To terminate only the load servers, click on Terminate All But Console button on the right-hand menu:

Once you finish the test you can download JTL files, graphs and CSV files to your local machine to prepare your report. Use the Files tab to download any files generated by JMeter and saved during the run. Use the JTLs tab to download any JTL or graphs you wish to use in your report.

Do not forget to use the Terminate Test button in order to terminate the remaining server.

Once you are done with your load tests, click Terminate Test on the right-hand menu and then click OK on the confirmation pop-up, in order to free the allocated servers and confirm the termination.

From your Load Testing Home page you can verify that the load test has terminated and is no longer active.

Another option is to first terminate all of the load servers, but keep the GUI console open. In this case the load is still terminated, but the load results are available for viewing and uploading to the website. To terminate only the load servers, click on the Terminate All But Console button on the right-hand menu:

When you no longer need to view the JMeter GUI console, click on Terminate Test button in order to terminate the remaining server.

All test runs logs, jmx scripts, saved results and graphs files are saved and available for download during and after the load run from the Files page.

Logs, JMeter jtl files and graphs images are zipped into one file located under the Zipped folder. 

You can use JMeter in the Cloud to record your script directly to the cloud environment. To do so, please follow the steps described bellow.

Launch JMeter Console

Choose Script creation only. Choosing this option will launch one server for the JMeter console and will allow you to record, write and debug your test script.

This step is not mandatory.

Discover Console Host Name

For the next step you will need a host name and port number for the proxy configuration.

The Console host name can be found Under Logs -> Network Information.

The PublicDNS field in the first line is the public host name of the JMeter Console.

Available Ports

You can choose any port from port 32000 to 64000. Any port below 32000 is closed. For example: port 32100 is a good port number, so is port 36150.

Browser Configuration

Now, configure your browser to use the JMeter Console as proxy using the host name and port number.

Further Instructions

Further instruction as how to use JMeter for recording can be found in here.

JMeter has some limitations especially when it is run in a distributed environment. Following these guidelines will assist in creating a real and continuous load:

1. Do not use the Console to create your load. You can use the console for debugging purposes or to run a small load from it to make sure the script is running correctly. The GUI consumes a lot of memory under heavy load, therefore the console server by itself can not sustain a heavy load.
2. Use the remote servers to create the load. Use the "Remote Start All" or "Remote Start" individual servers. Further information can be found in our User Guide section.
3. Limit the number of threads per engine to 300. This means the total number of threads generated by your test plan should be less than 300. The overall number of threads running from JMeter in the Cloud will be the total number of threads multiplied by the number of JMeterEngines. For example, a test plan with 200 threads and 4 JMeterEngines, will generate a load of 800 threads.
4. Disable the "View Result Tree" listener as it consumes a lot of memory and can result in the console freezing or JMeter running out of memory. It is, however, safe to use the "View Result Tree" listener with only "Errors" checked.
5. Disable all JMeter graphs as they consume a lot of memory. You can view all of the real time graphs using the JTLs tab in your web interface. Further information can be found in our User Guide section.
6. Monitor the logs. Any errors in the test plan or the test itself will appear in the log files that are available online under the Logs tab. For example: Out of Memory, disconnections etc.
7. Do not forget to erase the local path from CSV Data Set Config if used. Further information can be found in our FAQ section.
8. File names should include only alphanumeric characters, underscores or hyphens: [0-9],[aA-zZ],[_-]. File names should always include an extension.
9. Clean the Files tab prior to every test run.

Best Practice Using JTL files

If you are using JTL files, we recommend following these guidelines:

1. Assign a meaningful JTL file name. For example: 150210-4000t-1.jtl. Do not use spaces in the JTL file name.
2. Make sure that the JTL file is saved in XML format and not CSV.
3. Visit the JTLs tab at least once to generate the real-time reports.
4. Use the "Terminate all but Console" feature to finish your reports and download all graphics and CSV files.
5. Enable the Users vs Load Time Average report by following these instructions.
6. Use short and meaningful names for labels identifying controllers and samplers (for example HTTP requests). If you use long names, the names themselves will take the better part of the graphs generated using the JTLs tab.

SimpleTest is a new service by CloudIntelligence aimed to serve people that are not Load-Testing professionals.

If you are a Load-Testing professional, SimpleTest will bore you. We highly recommend using JMeter in the Cloud, which is a complete Load-Testing platform for the use of Load-Testing professionals.

If you are not a professional but looking for a complete turn-key solution for your Load-Testing project, including script creation, test execution and results analysis, you should use LoadIntelligence.

To use the SimpleTest service, you need to open an account at www.cloud-intelligence.com, register and choose Simple-Test service.

Choose the required landing pages that will participate in the test and the delay between each page request. Each landing page must include:

• A title that will assist in identifying the page in the reports
• A URL that represents the web address of the page. The URL should include the full address. For example: http://my.domain.com/landing/page?with=some&var=iables

You can include up to six landing pages.

 You need to specify the delay in seconds between each page request.

Each simulated user will call one page at a time from the list of landing pages. The user will pause for the specified delay between each page request.

Choose one of four global geographic locations from which the load will originate. At present we support East & West USA, Europe and Singapore.

Specify the maximum number of virtual users.

Once the test has started, users will ramp up to the maximum number in a period of 30 minutes. This number derives the number of servers that will participate in the test.

Using CloudIntelligence Load-Testing platform you can run unlimited size tests. However, at this time, we allow to run tests of size not greater than 4,200 concurrent virtual users. Soon we will allow unlimited size.

If you wish to execute a test of size greater than 4,200, please consider using JMeter in the Cloud.

Prior to starting the test you will need to purchase a test credit. Please follow the on-screen instructions that walk you through the purchase process.

Tests in a capacity of up to 100 concurrent users are free of charge.

We support various load scenarios. Each load scenario is different in the users ramp-up time and the continuous load after the ramp-up period.

Ramp-up time is the time it takes for users to ramp up from zero to the maximum capacity. The ramp-up time has a high influence over the website performance as the action of spawning a new thread/process to deal with a new user is very expensive in terms of resources.

Load Scenario - Users are gradually ramping up from zero to a full load capacity in a period of 30 minutes. The load then continues for additional 10 minutes and then stops.

Stress Scenario - Users are quickly ramping up from zero to a full load capacity in a period of 10 minutes. The load then continues for additional 30 minutes and then stops. In this case you are stressing your system for a period of 10 minutes, then the system is tested under continuous load.

Extreme Stress Scenario - Users are ramping up from zero to a full load capacity in a period of 5 minutes. The load then continues for additional 35 minutes and then stops. In this case you are testing your website under extreme stress conditions, where all users are ramping up with-in 5 minutes, then the system is tested under continuous load.

For example, imagine having a TV campaign, that encourages users to go to your website at a specific time. At that time your website can experience heavy traffic with-in a short period of time. This is a stress scenario, where users are ramping up from zero to a high volume in a short period of time.

If you just want to test your website under a load scenario than you do not want a short ramp-up period as it can overwhelm your server.

Embedded resources include all CSSs, JSs, Images and other resources that are part of a landing page. By downloading all embedded resources of each landing page, the response time of each landing page will be the total sum of response times for all embedded resources.

Disable this option if you want a request to be made only to the URL of the landing page and not to retrieve the embedded resources.

For example in case you are using a Content Distribution Network or smart caching of any sort for the static content, you should disable this option.

If you don't know if this is important to you or not, ignore it altogether.

Once you save the test you can start it by pressing on the Start link.

Once the test has started, please follow the instructions that appear on the page. The instructions will basically tell you to do nothing. After few minutes the reports will appear.

There is no hurry, as the test takes about 40 minutes to execute and the reports need some data to accumulate before they can generate.

Before running a load test on a website which is in a capacity greater than 100 users, we need first to make sure that you are the owner of this website. For obvious reasons we cannot allow to run a high capacity load test on a website owned by someone else.

To ensure website ownership, we require that you put a simple html file named cloudintelligence.html at the top level path of your website.

For example, if you are testing http://www.example.com/landing/page, a URL of the name: http://www.example.com/cloudintelligence.html must exist.

This action provides us with a proof that you are the owner of the website and therefore can run a load test on it.

Prior to running the load, we automatically check the availability of this file at all the domains specified in the test. If this check returns a false value on any domain, the load test will not run.

If for some reason you are unable to do so, please contact us and we will authenticate you and allow the tests to run.

A sample test (a test of up to 10 users) does not require these security/ownership measures and can run without the file being present on the domains under test.

Few minutes after the test has started, reports will begin to appear. Completed reports will be available only after it has ended.

Reports are generated in real time. To see an example of a live reports screen, please visit our demo section.

There are two types of reports:

1. Aggregated Reports
2. Detailed Reports

Aggregated Reports

Aggregated reports present various distributions of response times, latencies and errors throughout the entire test. These reports can draw the entire picture in a single snapshot.

Aggregated Reports include:

1. Two graphs: Response time distribution by percentage from the entire test and  according to the number of samples
2. Two graphs: Latency distribution by percentage from the entire test and  according to the number of samples
3. Two graphs: Error/Response Code distribution by percentage from the entire test and  according to the number of samples
4. One graph: Throughput distribution

Detailed Reports

Detailed reports present the average value of each measure per minute throughout the entire test.

Measures include:

1. Response time
2. Latency
3. Hits per minute
4. Number of concurrent users (Active Threads)
5. Errors
6. Throughput (in Kilobytes)

There is one view for all URLs that were included in the test and detailed views for each unique URL.

Detailed reports include:

1. Response Time and Latency Vs Users
2. Response Time and Latency Vs Hits
3. Response Time and Latency Vs Errors
4. Response Time and Latency Vs Throughput
5. Hits Vs Users
6. Hits Vs Errors
7. Hits Vs Throughput

To see an example of a live reports screen, please visit our demo section.

If you wish to see a different type of report, contact us and let us know.

SimpleTest is not a complete Load-Testing solution. It is not a substitute for a full test or for fixing any problem resulting from that test.

SimpleTest should be considered as limited performance checkup. In that sense, you will still need an expert to translate the findings. You will need an expert to solve any problems found. An expert may also recommend further steps.

A full test should include simulation of numerous business processes, different load scenarios over multiple iterations. All these are possible using JMeter in the Cloud Load-Testing platform.

Reports should give an initial picture of the status of your website performance and load endurance.

All the scripts and reports that were automatically generated are kept for you with-in your account in case you want to do some serious testing by using  JMeter in the Cloud.  

Please contact us if you want to use our professional services or have us recommend a service provider in your region.