Now that my blog is up and running again, I’d like to share the project I’ve been working on for 10 months.
I assume that you have some knowledge about performance testing. If not, don’t worry, I may post something about it soon.
The Beginning of a great project
Last year I’ve started my last internship as a student in a Paris-based company named eBusiness Information which is part of the Excilys Group. I’ve chosen this company to start my professional experience as a junior Java consultant.
One month or so after the beginning of the internship, the CTO of the company (Stéphane Landelle) asked me if I wanted to work on a new project with him. The project was his own idea: building a new stress tool that would be the most efficient and easy-to-use. As I love challenges and working with the latest technologies, I accepted (almost) without hesitation.
The project was destined to be open sourced from the beginning and Stéphane had already found a good name for it: Gatling. This was really exciting, thinking that I was finally contributing to the Open Source community with a new project.
State of the art
Even if the project is attractive from a developer point of view, I found myself wondering why a new stress tool should be made. This is were Stéphane helped me (I wasn’t really aware of performance testing at the time).
Existing Free Open Source Tools for the Java Virtual Machine (like JMeter) were not efficient.
Note that I wrote efficient, not effective.
He had to use stress tools when he worked as a consultant, and he couldn’t find one that was close enough of what he believes (and I agree with him) a stress tool should be.
One thread = One user
Most of the existing tools are using this paradygm where one user is represented by a thread. The idea is not bad, and 10 years ago, it made sense: the thread could be put to sleep to simulate the thinking time of users. This works, or developers wouldn’t have been able to stress applications in the last decade.
The problem is the effectiveness of such a model. The created threads are waiting for their turn most of the time, and when they don’t, they’re put to sleep. Moreover, the JVM was not created to handle hundreds of threads, so, when a simulation is run with thousands of users, the JVM is struggling with the scheduling. Thus, too much time is spent (in the CPU) scheduling the threads instead of actually doing what is needed.
Using one thread per user is a waste of resources, and it induces a loss concerning the effectiveness of the stress tool.
GUI & unreadable XML scenarios
Performance tests should be part of the development process as much as unit tests or functional tests. To do so, we might want to include the scenario files into our SCM to keep track of the modifications made between two versions of the application we are working on.
XML files generated by JMeter (for example) can be included in the SCM, but it is hardly readable. “What for?” may you ask; “there is a GUI!” That’s true: there is a GUI. But what’s the point in making a diff on a file without being able to understand the changes? Scenario descriptions should be readable and understandable by anyone.
High performance stress tool
After pointing out what we wanted to improve in stress tools, let me list the simple concepts behind Gatling that make it really efficient and easy-to-use:
- Asynchronous concurrency thanks to the actor model
- Asynchronous IOs
- Scenarios written as DSL
Actor model
Opposed to the “One Thread = One User” model, there is the actor model. This model (described in details on Wikipedia) consists in small entities named actors communicating via messages (asynchronous concurrency). They are composed of:
- a Mailbox which stores all the messages received
- a Computation Unit which executes a predefined action for each received message
This allows the Gatling engine to be more efficient and reduces drastically the number of threads needed to run lots of users (~50 threads for 2000 users in Gatling’s case).
To use actors, we rely on the Akka actor library, which is really efficient and part of the Typesafe Stack.
Async IOs
To benefit fully from the actor model, we also used asynchronous IOs. This allows actors to send a request to the tested application, and pass to the next message they received instead of waiting for a response. This saves a lot of time (imagine how long an actor could wait if a response timed out…).
To send these asynchronous requests, we use the Async HTTP Client library created by Jean-François Arcand with Netty as the underlying HTTP library.
Scenarios as code: DSL
We created a Domain Specific Language (DSL) to describe scenarios in Gatling. This was achieved thanks to the builder pattern, so Java programmers will understand it really easily.
Scenarios are actually Scala code. Indeed, it is the language in which Akka is written and thanks to its functional nature, it allows great scenarios extending without the need to modify Gatling’s core code.
Conclusion
We think that Gatling can make a huge difference for performance testing. The result of our work is an easy-to-use application, and, as we expected, a really efficient engine! Gatling has its name right: it blasts your applications without burning your resources :-)
I could write longer about Gatling, and how we made it, but I think that this post is long enough for a presentation of the project. I invite you to check out Gatling’s website for further information.
We have a quite complete documentation available on the project’s wiki, and examples of simulations are available in the downloadable bundles.
I’m proud of what we did with Stéphane and I thank him and my company for letting me work on this software.
One last word: if you like Gatling, spread the word ;-)
