This blog post was originally written for the Rackspace DevOps blog. Check out this post and more great dev advice on their blog.
…….
Web application performance is a moving target. During design and implementation, a lot of big and small decisions are made that affect application performance – for good and bad. You’ve heard it before. But since performance can be ruined many times throughout a project, good application performance simply can not be added as an extra feature at the end of a project.
The modern solution to mitigate quality problems throughout the application development life cycle is called Continuous Integration, or just CI. The benefits of using CI are many, but for me, the most important factor for embracing CI is the ability to run automated tests frequently and to trace application performance, since such tests need to be added to the stack of automated tests already being generated. If you have load tests carried out throughout your project development, you can proactively trace how performance is affected.
The key is being able to automate load testing. But how do we do that? Naturally, it depends on your environment. Assuming that you’re building a web application and that your build environment is already in the cloud, it would be ideal to start using a cloud based load testing service such as Load Impact to automatically generate load and measure performance. In fact, libcurl will get you almost all the way.
Load Impact’s Continuous Delivery API was created to enable developers to run load tests programmatically. It’s an http based REST API that uses JSON for passing parameters. In its most basic form, you can run the following from a command line:
$ curl -X POST https://api.loadimpact.com/v2/test-configs/X/start -u token: {"id":Y}
$ curl -X GET https://api.loadimpact.com/v2/tests/Y/results -u token: > out.json
In this example X = the LoadImpact test config id, Y = the test result id and token = your LoadImpact API token. Please note that token is sent as an http username but with a blank password.
Since JSON is not that easy to work with from the command line, using PHP or Perl to wrap the calls in a script makes sense. A more complete sample doesn’t really fit into this blog post, but at a pseudo level you want to:
<?php
$token = '123456789';
$urlbase = 'https://api.loadimpact.com/v2/';
$config_id = 999;
// Start test and get id from JSON return
$test = http_post($urlbase . "/test-configs/$config_id/start"));
$done = FALSE;
while(!$done) {
sleep(30);
$status = http_get($urlbase . "/tests/{$test->id}");
$if($status->status > 2) $done = TRUE;
}
$result = http_get($urlbase . "/tests{$test-id}/results");
$last = count($results->__li_user_load_time);
echo $results->__li_user_load_time[$last]->value; ?>
First, some variables are set, the existing test configuration id and my API token being the most interesting.
Second, I ask Load Impact to launch the test configuration and store the test id. Wait for the test to finish by asking for its status code every 30 seconds.
Lastly, when I know the test if finished, I ask for the test result that I can then query for values. In this example, I simply echo the last measurement of the actual load time. If needed, the Load Impact API also allows me to manipulate the target URL before I launched the test, change the number of simulated users or make other relevant changes.
Running repeated load test as part of your CI solution will reveal a lot about how an application’s performance is affected by all those small decisions.
Note that you probably don’t want to run a full set of exhaustive performance tests at every build. I recommend that a few well-selected tests are executed. The key is to get a series of measurements that can be tracked over time.
- Automating Load Testing (developer.rackspace.com)
Load Impact Blog 