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.

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:

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.

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

Hi
I tried with feeders and it worked well. As a loadrunner script , how to replay the script by handling dynamic values just like Web Reg save param function does ??
More that , do We need to learn scala to work with gatling ?

I don’t need to learn Scala to work with Gatling. The scenario configuration file is in Scala but it is using its own DSL and I don’t find it more complicated to update it than updating an XML or a JSON file.

About Web Reg Save and loadrunner, I am not familiar with LoadRunner so I can not answer on this one.

Thank you for the tutorial. Have you tried to use this through HTTPS traffic? I am attempting to do so but am getting this error
“15:02:01.810 [WARN ] i.g.h.a.AsyncHandlerActor – Request ‘request_0’ failed: javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name”.