SIPP and Jenkins

Flow

I start with the Dashboard having a project which first sets up the data for the test:

The JMeter set up is pretty straight forward... it's the parent project and the Working directory is set ot the JMeter installation folder. The Shell script is set to  kick off the JMeter script that seeds the data for the test.  Afterwards it kicks off the downstream project, which runs the load.

The load itself is just the SIPP command line:

The Post Process here is to email out the CSV results to a distribution list.... and clean up the test data.

Organizing SIPP with Jenkins

In my organization, I work on a team that's business is both a web application and a SIP protocol.  To that end I work in both Java created code and C created code.

The UI I automated with Cucumber, but when it came time to create Load and Performance tests of the SIP side of things, I turned to SIPP.

SIPP is a command line unix tool that lets you drive SIP traffic to a virtual PBX proxy (FreeSWITCH, Asterix, etc.)  You can simulate calls by driving RTP traffic (as recorded pcaps) as well as send DTMF tones to navigate IVR's.

SIPP tests are controlled equally via the command line, as well as in a scenario file.  This is where it gets cumbersome.  You can store all the scenario files, and you can put them in git or subversion... but you still need to remember all those command line parameters for your tests.

I decided to utilize Jenkins for this.

I set up a local installation of Jenkins to handle the Load Tests only.  Each Jenkins job is really just a drive of a command line.  For example, a Jenkins build called "2,000 SIP calls @ 10 calls per second" would be a build process of simply running a shell script: ./sipp -s [service name] [your proxy] -sf [your scenario file] -r 10 [sets the rate to 10 per 1 sec] -m 2000 [the number of calls] -trace_rtt [calculates the response time you defined in your scenario file and outputs the results to a csv file] -trace_err [outputs any errors]

When this Jenkins job is built, it runs the command line that drives the scenario file with those parameters specified.

Then I have Jenkins mail me the csv file created.  Integrating the output to Jenkins would be great, but it requires reworking some performance plugins.  At this point, I'll just handle the graphs in excel from the csv data.

Upstream

I created a Higher Level project to set the data. This occurred when some of the load tests were run, the number they were hitting as being configured incorrectly via the Web Application.  Not knowing the state of the previous web application would cause the tests to sometimes get directed to the wrong locations.... i.e. all the load going to a forwarding action to another number, or going to a fax line.

To resolve this, I added a simple JMeter script as the parent project.  It does several put requests, setting all the data as expected, then immediately kicks off the downstream project which runs the SIPP tool to kick off the SIP load.

Further Downstream

After the Email is sent out, I didn't want a ton of CSV files cluttering up the workspace, so I have a final clean up project that moves the csv's to archive.

End Result

The end result is a fully automated SIP load process, via a web interface that can be accessed anywhere on the network.

A user goes to Jenkins, clicks on a Project like "2,000 SIP calls to Integration @ 10 calls per second" and clicks build.  In a few min, an email with results is sent out to them.

It can be further improved, but it's a great start that really makes organizing the SIP scenarios and command line parameters feasible, as well as giving an easy to use interface to run load tests ad hoc.