Stress test your Flex application using Jmeter and EC2

A while back, a client needed to stress test his application. Since I had some experience with JMeter before, and was eager to try out Amazon’s EC2 (Elastic Compute Cloud), this is the setup I offered.
Turns out it worked remarkably well.
Detailed explanation and utility files/scripts follows…

* Note: the information below was gathered from a myriad of blogs, forums and hectic googling. Unfortunately, I don’t remember what information I got where, so apologies if you read this and think I reaped you off – please contact me and I’ll add the proper credit.

And now, on with the show!

So, you want to run a Jmeter scenario on cloud computing….

First, lets create a Jmeter scenario:

  1. Download Jmeter from and unzip it (say c:\jmeter).

  2. Edit jmeter executable and modify HEAP variable to whatever you like (-Xms1024m -Xmx1024m)

  3. Run Jmeter by running c:\jmeter\bin\jmeter and you’ll see the Jmeter gui with the basic scenario tree – TestPlan and Workbench.

We need to setup Jmeter to be able to record a scenario.

We’ll use a proxy to record a test plan. Note, that Jmeter does not support HTTPS. Since HTTPS is secure, the proxy is unable to decrypt the traffic and record the request parameters or cookies.

  1. Select “test plan” on the tree

  2. Right click on the “test plan” and add a new thread group: add -> thread group

  3. Select the thread group

  4. Right click “add -> config element -> Http Request Defaults”

  5. Protocol – enter “HTTP”

  6. Server name – enter the host name

  7. Path – leave blank

  8. Port number – enter “80”

  9. Right click on workbench and add the Http proxy: add -> non-test elements -> Http Proxy Server

  10. Port field – Enter “9090”

  11. Target Controller – click on the drop down and select “test plan > thread group”

  12. Click the “add” button in “Patterns to include”. This will create a blank entry.

  13. Enter “.*”

  14. right click the proxy server → add → timer → gaussian random timer.

  15. In the constant field enter ${T} and in the deviation enter a number in millisecs (i.e. 500).

  16. Click the “start” button at the bottom

  17. Start Internet Explorer, but do not close Jmeter.

    As a general tip, it is a good idea to set the homepage for your browser to a blank page. This way, it reduces the number of unwanted pages Jmeter records during the session. It is a good idea to try the proxy with different sites and get comfortable with different filtering patterns. Also, close all programs like messenger, pidgin etc. that use the same proxy settings as IE, as that will add junk to the scenario.

  18. From the tool bar, click “tools -> internet options”. This should bring up the options.

  19. Select the “connection” tab

  20. Click “lan settings” button near the bottom.

  21. On the connections tab, check “Use a proxy server for your LAN”. The address and port fields should be enabled now.

  22. Address – enter “Localhost” or the IP address of your system

  23. Port – enter “9090”.

  24. Click “ok” button

  25. Click “ok” button again. This should return you to the browser

You’re done with Jmeter and IE setup – Woohoo!

Now, we’ll record the scenario:

  1. In the “Address” bar at the top, enter the url to record and hit the “enter” key.

  2. Do the actions you want to be recorded.

  3. Close internet explorer and bring up the Jmeter window.

You’re done with the recording phase! Aren’t you happy?

Let’s review the test plan

To be able to see statistics on the scenario, we’ll add some reports.

  1. Select “thread group”

  2. Right click “add -> listener -> aggregate report” to add an aggregate listener. The aggregate listener will show some basic statistics.

  3. Select the aggregate report

  4. You can configure a filename to specify where to dump the report data, filter only errors, successes, all or none, and configure what data is displayed.

  5. Select “thread group”

  6. Right click “add -> listener -> summary report” to add a summary listener.

  7. You can set the same settings as you did for the aggregate report.

Note: Some HTTP POST requests chain multiple argument sets with ‘\n’. Jmeter misunderstands this and does not play the scenario properly. In this case, you will have to Manually edit the resulting scenario JMX file and split those into separate requests.

Ready…. Set…. GO!

  1. To run the scenario, select “thread group”

  2. Number of threads – the number of “virtual users” Jmeter will emulate. There will be a thread running the scenario for each virtual user.

  3. Ramp up Period – the time to wait before starting a new virtual user.

  4. Loop count – the number of times to repeat.

  5. Run → Start to start running.

While the test is running, in the upper right-hand corner, there should be a green square.
When the test is done, the box should be gray.

Note: To launch scenario in a distributed configuration, start each jmeter server as jmeter- server,
and run the managing instance as: jmeter -n -t <scenario.jmx> -l <log.jtl> -RserverInstance1,serverInstance2… &

What’s next: Setting up Amazon EC2.

We’ll be using Amazon’s cloud computing service (aka EC2/S3). I’ll be assuming you already have an account with Amazon. If you don’t, create one, and save the cert-XXX.pem and pk-XXX.pem key files.

What we’d like to achieve, is a machine image (AMI) stored on S3 service, which will have Jmeter already installed. That will let us create instances of that image when needed.

Setup your local machine

  1. Download EC2 tools from here:

  2. Extract to some directory. I’ve installed them at /root/.ec2

  3. Create a ‘keys’ directory under /root/.ec2

  4. Install JRE>=1.5

  5. Export/set the following environment variables; JAVA_HOME, EC2_HOME, EC2_PRIVATE_KEY, EC2_CERT, PATH. You could simply add these to your .bashrc file:

export JAVA_HOME=/usr
export EC2_HOME=/root/.ec2/ec2-api-tools
export EC2_PRIVATE_KEY=/root/.ec2/keys/pk-XXX.pem
export EC2_CERT=/root/.ec2/keys/cert-XXX.pem
export PATH=$EC2_HOME/bin:$PATH

Your local machine is ready! Happy happy joy joy!!!
Now, you can start using EC2 commands.

Creating an AMI

The easiest way to create an AMI is to use an existing public one and install what you need over it.

  1. Select an AMI
    The first step is to locate an AMI that contains the packages and services that you require. This can be one of your own AMIs or one of the public AMIs provided by Amazon EC2. Use ec2-describe-images to get a list of available AMIs, then select one of the listed AMIs and note its AMI ID, e.g. ami-4b709422 (Ubuntu 8.10 64bit).

  2. Generate a Keypair
    This step is only required if you’ve selected one of the public AMIs provided by Amazon EC2 (which we do). A public/private keypair must be created to ensure that you, and only you, have access to the instances that you launch. ec2-create-keypair key1 – the result will be something like:

    KEYPAIR key1 1f:51:ae:28:bf:89:e9:d8:1f:25:5d:37:2d:7d:b8:ca:9f:f5:f1:6f

    -----END RSA PRIVATE KEY----- 

    The resulting private key must be saved in a local file for later use. Create a file named key1-keypair in /root/.ec2/keys and paste into it all lines starting with the line

    -----BEGIN PRIVATE KEY-----
    and ending with the line

    -----END PRIVATE KEY-----“.Confirm that the file contents looks exactly as shown below.



    Make sure that only the owner can read & write to that file. i.e.
    chmod 600 /root/.ec2/keys/key1-keypair

  3. Launch an instance of the AMI you selected above:
    ec2-run-instances ami-4b709422 -k key1 -n 1-1 -t m1.large
    the result will be something like
    INSTANCE i-10a64379 ami-5bae4b32   EC2    pending   key1

    The instance ID in the second field of the output is a unique identifier for the instance and can be used subsequently to manipulate your instance, e.g. to terminate it.Important: Once you launch an instance, you will be billed per hour for CPU time. Make sure you terminate any instances which you don't intend to leave running indefinitely.It will take a few minutes for the instance to launch. You can follow its progress by running: ec2-describe-instances i-10a64379

    RESERVATION     r-fea54097  495219933132   EC2
    INSTANCE        i-10a64379  ami-5bae4b32 EC2 running key1

    When the status field reads “running”, the instance has been created and has started booting. There may still be a short time before it is accessible over the network, however. The DNS name displayed in the sample output above will be different from that assigned to your instance. Make sure you use the appropriate one.

  4. Authorize network access In order to be able to reach the running instance from the Internet, you need to enable access for the ssh service which runs on port 22:
    ec2-authorize default -p 22
    PERMISSION default ALLOWS tcp 22 22 FROM CIDR

  5. Connect to the instance
    ssh -i /root/.ec2/keys/key1-keypair

  6. Now you have complete control over the instance, and you better change the root password to something else.

  7. Upload your Amazon Web Services (AWS) private key (PK) & certificate (CERT) files to that instance.
    You can use
    scp to do this.
    scp -i /home/azeez/.ec2/keys/key1-keypair pk-XXX.pem cert-xxx.pem new AMI will be encrypted and signed to ensure that it can only be accessed by you and Amazon EC2. You therefore need to upload your Amazon EC2 private key and X.509 certificate to the running instance, for use in the AMI bundling process.

    It is important that the key and cert files are uploaded into /tmp to prevent them being bundled with the new AMI.

  8. Install Java
    sudo vim /etc/apt/sources.list

    Ensure that the following two sources are added to the configuration file:
    deb intrepid main restricted
    deb intrepid multiverse

    After the configuration file is updated, the package repository needs to updated with the following command:
    sudo apt-get update

    To install Java version 6, the following command needs to be executed:
    sudo apt-get install sun-java6-jre

  9. Install Jmeter
    Download and install Jmeter, and scp the scenarios you’d like to run.

  10. Bundle the AMI



8 Responses to Stress test your Flex application using Jmeter and EC2

  1. Great site this and I am really pleased to see you have what I am actually looking for here and this this post is exactly what I am interested in. I shall be pleased to become a regular visitor 🙂

  2. Taljalge says:

    excellent site this nice to see you have what I am actually looking for here and this this post is exactly what I am interested in. I shall be pleased to become a regular visitor 🙂

  3. Taljalge says:

    nice site this terrific to see you have what I am actually looking for here and this this post is exactly what I am interested in. I shall be pleased to become a regular visitor 🙂

  4. Savio says:

    I have flex app that i am load testing…it seems that if there is an insert query or stmt running in the recorded scenario, the data gets inserted into the db during the scenario….but when i run the scenario the data doesn’t get inserted and no errors shown in the Result Tree Listener…..

  5. backcountry says:

    Thanks very good for report, I follow your blog.

  6. Thanks for posting this, I am currently looking for the master slave set up for Jmeter within the cloud. Any ideas on controlling multiple cloud instances running Jmeter would be appreciated.

  7. flexblackbelt says:

    If I remember correctly, you start JMeter on each slave and then start another JMeter in master mode and list the IPs of the slaves. I think it’s -s [IP, IP,…] but not sure, check the documentation.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: