I was looking for a stress tool to test a java product via its HTTP API.
Gatling was in my “to try list” for a couple of reasons:
- I listened to an interesting interview podcast by Emmanuel Bernard for Les Castcodeurs (in french)
- I missed the session at Devoxx France 2013 (note for later: watch the video)
- I saw it in the “trial” radar of Thoughworks http://www.thoughtworks.com/radar
I gave it a try and my first impressions were very good.
The wiki has a very good “getting started” and “first steps” sections with useful examples.
I propose here to show an alternate set of “first steps” by stress-testing Jenkins.
Here are my steps (on a Mac Book Pro with os x 10.8.3)
1) installation and configuration of jenkins
I discovered there is a one click install of Jenkins for MacOsX.
http://jenkins-ci.org/content/thank-you-downloading-os-x-installer
Jenkins is automatically launched and ready to be used.
Server can be accessed over HTTP on: http://localhost:8080/
I created a fake job that does nothing and launched it a couple of time to have some history:
2) installation of Gatling
I chose to download the 1.5.1 instead of the 2.0 as this last one is still under development and because 1.5.1 seems to have the feature I need.
I followed the “getting started” wiki page
Basically the installation and configuration was, here again, very quick:
- unzip
- launch 3 shell command :
sudo sysctl -w kern.maxfilesperproc=200000
sudo sysctl -w kern.maxfiles=200000
sudo sysctl -w net.inet.ip.portrange.first=1024
and that’s it!
3) preparation of the simulation
For our test of jenkins, we will use the recorder to write the simulation script.
The recorder will allow us to create a script that mimick what users could do on Jenkins.
For this simple example, we will just click on the job, click on a build and click on “console output” for this build.
First, we set-up Gatling’s recorder:
- launch the recorder
- set-up the recorder as proxy under Firefox
Now that Gatling recorder is ready :
- connect to jenkins via Firefox on http://localhost:8080/
- click through the links as a user would do
This creates a scala script in /path/to/gatling/user-files/simulations/Jenkins
You can take a look a the generated code (I added some comments in the file)
4) stress testing jenkins
If we launch the script as it, we will simulate the connection of a single user.
The reports gives a global view of the result of the test with the stats for the 22 requests performed.
To see what happens when 500 users connect simultaneously on my server, I just have to change the last part of the script to:
setUp(scn.users(500).protocolConfig(httpConf))
The result shows that half of the request1 performed failed (260 out of 240).
Failures are caused because Gatling will consider a request times out after 60 seconds.
Note that this timeout is defined in path/to/gatling/conf/gatling/conf
To be a little more realistic, we can simulate the fact that all the users are connecting gradually during 1 minutes (the whole 100 people of the R&D are checking the console output of the main job from 8h00 to 8h01 in the morning for example !). This can be scripted like that:
setUp(scn.users(500).ramp(60).protocolConfig(httpConf))
In that case, only 20 requests failed and other parts of the reports are interesting to look at.
- Number of active active sessions:
=> we can see the growth during 1 minute and gradual shutdown
- Number of requests per seconds
=> we can see that the 20 requests that fails are in the middle of the simulation when we reach the maximum number of active sessions
5) conclusion
This test is not very realistic for many reasons like:
- there is no network involved as I do everything on my laptop
- Jenkins user will retrieve bigger content on jenkins and have different behaviors
Yet, it is a good start and quite easy to perform.
Next steps would use more advanced features of Gatling.
Would you have any questions or experience to share, don’t hesitate to contact me.
If I have more to share on the topic, expect a follow-up.