Home > ServerTemplates > Open Source > Siege Load Tester > Siege Load Tester - Tutorial

Siege Load Tester - Tutorial

Table of Contents

RightScale Open Source

Useful ServerTemplate assets

Overview

► Tutorial

Runbook
Reference

RS Open Source Disclaimer

ServerTemplates published by "RightScale Open Source" consist of assets published by RightScale that do not belong to a standard LTS or Infinity branch. They are typically developed by one of the Professional Services, Technical Support or Sales Engineering teams. As such, they do not go through the more rigorous QA and testing cycles. Support is via the RightScale Community and a Service Level Agreement (SLA) does not apply.

Note: Not all RS Open Source assets are documented on the Support Portal. See the MultiCloud Marketplace for additional RightScale Open Source ServerTemplates.

Objective

To launch a server that's specifically designed to test web-based applications by sending simulated real-world traffic.

Prerequisites

'actor', 'designer' and 'library' user role privileges in the RightScale account.
A deployment with running application servers and a load balancing tier. This tutorial assumes that you have a running deployment that is similar to one of the 3 tier deployment setup tutorials. See ServerTemplates.
An active (enabled) server array that's configured for autoscaling. Recommended settings for this tutorial are as follows:
- Default min count: 2
- Decision threshold: 51%
- Resize Up by: 2
- Resize Down by: 1
- Resize calm time: 15
Alerts for resizing up and down (grow/shrink) the server array. Recommended alerts specifications are as follows:
- Scale Up: If cpu-0/cpu-idle.value < '30' for 5 min then vote to grow array by setting the tag 'YourTag'
- Scale Down: If cpu-0/cpu-idle.value > '70' for 5 min then vote to shrink array by setting the tag 'YourTag'

Overview

This tutorial is useful to test a deployment to make sure that its application tier is properly configured to autoscale. In this tutorial you will launch a server that can be used to simulate load in order to trigger your alerts so that you can force an autoscaling event where additional application servers would be launched into the server array. In this example, the 'cpu-idle' metric is used to trigger an autoscaling event.

Steps

Launch a Load Tester Server

Although you can add the load tester server to the same deployment that you are testing, you may find it more useful to create a separate deployment (that only contains a load tester server). With this approach you can continue to repurpose the server and test multiple deployments. It will also prevent the deployment that you're testing from being cluttered with unrelated inputs.

Create a new deployment and name it accordingly. (e.g. Load Tester) See Create a New Deployment.
Go to the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the following ServerTemplate into the RightScale account. (Requires 'library' user role privileges.)
- Siege Load Tester
Add a server to the new deployment.
Important!
Be sure to use an instance type that has better CPU performance than the application servers that are going to receive the load. For example, if you are using AWS and your application servers are 'm1.small' you should select a 'c1.medium' instance type for the Siege load tester server.
Launch the server. (No inputs are required.)

Create a RightScript for Load Testing

Although you can SSH into the load tester server (once it becomes operational) and run one of the sample Siege commands outlined in the ServerTemplate's Info tab, you may find it useful to create a simple RightScript that you can run on the server using the 'Any Script' option. Once you are satisfied with the script's parameters you can clone the ServerTemplate and add it as an operational script to streamline testing.

Load Test CPU

The following sample code simulates growing user traffic to a specified URI for about 40 minutes (one cycle per minute).

The scripts starts with 50 (5*10) concurrent users making a request for the URI specified by the LOAD_TEST_URI input and increases by 10 users every minute for 40 cycles.

Copy the sample code above and create a new RightScript. Be sure to give it a descriptive name. (e.g. Siege - Load Test CPU) See Create a New RightScript.

Note: There is no need to wait for your server to become operational before completing this step.

#!/bin/bash -ex

for i in `seq 5 40`; do
  /usr/local/bin/siege -c"${i}0" -d2 -t1M $LOAD_TEST_URI
done

Run the Load Test

If you created a RightScript to perform the load test, go to the Scripts tab of the Load Tester Server and run the new RightScript using the 'Any Script' option. You will only need to specify a value for one missing input.

Input Name

Description

Example Value

LOAD_TEST_URI

Enter the full URI that will receive the load (requests). (e.g. http://www.example.com/test.php) In order to make sure that an application server's CPU is significantly impacted by the load test, be sure to specify a page that requires a lot of CPU to load, such as a file that performs several calculations like generating a thousand unique MD5 strings. (Note: Simple HTML pages do not require a lot of CPU to load.)

If you are using RightScale's sample application located in the 'unified_php' branch and want to trigger an alert that's based on a server's CPU load (e.g. 'cpu-idle') point to the 'md5.php' file, which generates 1000 unique MD5 hashes. (e.g. http://www.example.com/md5.php) To generate more than 1000, append the loop directive at the end of the URI. (e.g. http://www.example.com/md5.php?loops=5000)

text: http://www.example.com/md5.php

Monitor the Application Servers

The next step is to monitor the graphs and voting tags.

Phase 1

When the script starts to send load, you will start to see the application tier being impacted. (Navigate to your YourDeployment > YourArray > and note the CPU thumbnail on the Instances tab)

Phase 2

The number of concurrent users will continue to increase and eventually provide enough load onto the application servers until they become overworked and start to vote for a "grow" autoscaling event because they need additional application servers in order to handle the amount of traffic to the site. In this example, the server array is configured to launch two additional instances when the "grow" alert is triggered.

Phase 3

Once the new application servers become operational, they will automatically connect to the load balancing pool and start to take some of the load off of the original application servers. Notice that the two additional application servers provide enough help to make the alert go away. As a result, the original application servers are no longer voting for a scale up action. (rs_vote:dean=none)

Phase 4

Once the script completes its cycles and stops sending load to the application servers (i.e. the spike in traffic ends), the application servers will start to vote for a scale down action. (rs_vote:dean=shrink) As a result, the oldest instance in the array will be terminated because the array is configured to scale down by one. (Resize Down by: 1)

Phase 5

If there is very little traffic hitting the application servers, eventually the server array will resize down one more time and return to its base configuration of two application servers.

Post Tutorial Steps

Once all of your tests are completed, you can shutdown the server you ran the Siege load test script from to load up your application servers.

Siege Load Tester - Tutorial

Table of Contents

RS Open Source Disclaimer

Objective

Prerequisites

Overview