Everything you need to get up and running with Tsung for load testing.
This code has only been tested with Amazon Linux (a RHEL 6 variant) in AWS. Although, it shouldn't be difficult to modify for other providers and operating systems. Pull requests welcome!
Use the Terraform configuration included in this repo. Read the README for details on how to set that up.
Once your infrastructure is created, you'll need to reference information about your instances to configure ansible (such as private and public IPs and hostnames).
There are two files you need to update, ansible/vars/tsung_config.yml
and your ansible inventory file in ansible/hosts/
.
Add each of your Tsung nodes that will be actually making requests to the clients:
section of the file. You will need to choose a single node to act as your controller. The details of that instance need to be added to the controller:
section.
Use ansible/hosts/example.ini
as an example. The file name doesn't matter, but for the rest of these steps, we use myhosts.ini
as the file name. This file contains info about all of your Tsung nodes so that ansible can connect to them, install tsung, and run the tests.
Ansible playbooks are included to handle this for you. Erlang and Tsung are built from source on each of your Tsung nodes.
> cd ansible;
> ansible-playbook install.yml -i hosts/myhosts.ini
Tsung runs a series of scenarios to mock user traffic. Sessions define the payloads used in testing. Learn about sessions.
Recording sessions can be done locally pretty easily. Refer to the Tsung proxy recorder docs to configure. Tsung can record/play sessions over http, websockets, database protocols, LDAP, Jabber/XMPP, etc.
Important Note: When your sessions are recorded, review the output xml to make sure you remove any requests to third party sites and services. You don't want to be DDoS-ing anyone unknowningly.
In ansible/vars/run/sessions/
, add your recorded sessions. Read the docs for details. It should look something like this:
<sessions>
<session name='best-buy' probability='20' type='ts_http'>
<request><http url='http://example.com' version='1.1' method='GET'></http></request>
</session>
</sessions>
Note: Be sure to convert all ampersands (&) to &
in HTTP URLs, or you may get a expected_entity_reference_semicolon
error.
Next, define your load phases in ansible/vars/run/loads/
. Refer to the manual for more details. Here's an example:
<load>
<arrivalphase phase="1" duration="5" unit="minute">
<users interarrival="1" unit="second" maxnumber="1000"></users>
</arrivalphase>
</load>
When you've got your session and load files prepped, update ansible/vars/tsung_config.yml
with the proper paths for load_file
and sessions_file
. Then upload the configuration to your Tsung controller:
> cd ansible
> ansible-playbook config.yml -i hosts/myhosts.ini
This will start your test:
> date; ansible controller -i hosts/myhosts.ini -a "tsung start"
Tsung makes a web interface available to view the status of your test. To view the status of Tsung while it's running, go to http://controller-ip-or-hostname:8091/. The status page will not be available when Tsung is not running.
If you decide to use the Tsung, please keep in mind the following important caveat: Tsung is, more-or-less a distributed denial-of-service attack and, therefore, if you point them at any server you don’t own you will behaving unethically, have your provider account locked-out, and be liable in a court of law for any downtime you cause.
Keep in mind that you may need to notify your hosting provider of any load or performance testing you are doing. Check with your provider for more info.
You have been warned!
Some of this verbiage was taken from another awesome load testing tool to have in your toolbox called beeswithmachineguns.
MIT License