You have just completed the development of your amazing new API, you’re excited, it looks very fast in your development environment, in your stage environment too…let’s go to production then! And…boom! You suddenly realise, in the worst way possible, that your API is not performing well when lots of users are really using it. Many concurrent requests are contending for resources making the whole system unstable. Is the available memory not enough for your new functionality? Is your algorithm not very efficient? Is the load you put on your database too high? Well, any of these options can be true, and would be good to know it before releasing your new software to your customers. A performance test, also called stress test, can come to the rescue in this circumstance. I’ve recently heard about a “stress tool” called Gatling and I’ve spent some time playing with it, so today I’ll be writing about the basic features that it provides.
simulate your users
In order to test a real usage of our API you need real users. Obviously that’s not possible until the API is in production, so, what about fake users? Gatling allows you to simulate the behaviour of a typical user of your API, in terms of the HTTP requests that are likely to be made and their order. Gatling calls scenario the representation of the behaviour of a typical user. You can also probably have different kinds of users, with different behaviours. In that case you will need to define several scenarios, in order to form a simulation, another of Gatling’s main concepts. For each scenario it’s then possible to define how many users should be simulated and also to decide if we want them to make requests at the same time or with a particular timing (more on this soon).
nice domain specific language
We’ve learned so far that Gatling makes possible the definition of a simulation as a collection of scenarios, but how? Well, providing a very nice, fluent and simple DSL (Domain Specific Language). Gatling is written in Scala, so your simulations will be Scala classes. Although a basic knowledge of Scala is recommended, the DSL is so simple that you’ll probably be able to write your simulations without much effort. Below there’s a simple simulation I wrote for a demo, that calls a couple of endpoints exposed by our Twitter ingest system, Canary.
As you can see the code is pretty simple and almost self-explanatory. I’ve defined a scenario in which two HTTP requests are made, one that asks for a Twitter user’s details, the other one that asks for the timeline of the same user. For each HTTP request the status code and the response time are checked, in order to make sure that the request was served successfully and within a reasonable time.
Note that I used the method
feed with a csv file name as a parameter. That gives me the possibility to construct the URLs dynamically, using different user names (contained in that csv file) every time. That
twitter_users.csv looks like this (note the
username header that is the same used in the URLs using the notation
The last thing to note in the example is the last line: with the
setUp method we can define the scenario we want to run and how many users we want to simulate for that scenario. I’m simulating 100 users and I’m also stating, with the method
ramp, that I want them gradually starting in a time of 5 seconds. This allows us to simulate a more real scenario, when is not likely that all the requests will happen at the same time.
useful report generation
After you run your simulation Gatling will come up with a pretty nice HTML page containing several useful statistics and graphs that will help you to understand how your API performed. You can have a sample of what you can expect from the report generation by looking at the picture below, kindly provided by the Gatling’s website.
there’s more to discover
This was a quick introduction to this pretty useful stress tool. There are obviously several other features you can use in order to shoot at your API and be aware of eventual performance issues as soon as possible. There’s also a new version of Gatling that is currently under development and looks quite promising.
Do you have any experience with stress tests? Have you ever tried Gatling or any other similar tool? We would like to hear your opinion, so feel free to leave a comment below or to tweet us.