Today agile development, TDD and continuous deployment are well adopted concepts and load testing shouldn't be conducted at some later moment in a project, but as soon as possible and on a regular basis.
Gatling - an open source stress testing tool for web applications
The Gatling project was born 4 years ago out of frustration towards other web load test tools. Most tools suffered from many shortcomings like poor throughput, memory leaks and bad usability. They especially did not match how testers and developers work nowadays.
For example, one thing here was that most test tools were and still are pretty much GUI oriented. Using a GUI for testing gives a false sense of easiness, but actually makes things harder once you try to go beyond a hello-world-like sample. It also makes test case maintenance harder as you have no efficient way to compare test versions, rollback, refactor, comment, and so on.
Gatling stress testing tool emphasizes the following principles:
- Performance - Based on Akka and Netty, Gatling has a nice non-blocking architecture that optimizes resource usage.
- Test case maintainability - Gatling provides a DSL that mimics protocols such as HTTP. This makes the scenarios easy to read.
- Test as code - In real life, whatever the tool, it's very common to hit some feature that's very specific to your use case and isn't built in the tool, and you need to customize the behavior. In Gatling, scenarios are actually code, so you can customize everything - even write your own APIs.
- Analysis - Gatling provides good-looking HTML reports that you can share, archive on a web server or version management.
Gatling v2 and websocket testing
New Gatling 2 introduces polished APIs, new HTTP engine, supports of new protocols (WebSockets and JMS) and even 60% throughput improvement on some high velocity use cases. Version 2 also adds API for websockets, which makes it an interesting tool for testing new push-enabled Vaadin applications.
Like we know, the websocket model is very different from the traditional HTTP request-response pair, and so is the load testing of applications using it. It's purely asynchronous, and messages can be initiated from the client as well as from the server. If you want to mimic the behavior of a browser, you also have to synchronize the state from your websocket flow, and the state of your classic XHR flow.
Websockets are still pretty new technology, and they can have a critical impact on your infrastructure: proxies, load balancers, cloud hosting. If you're building Vaadin apps with websockets, you definitely have to perform some load testing and check that your system behaves as expected.
Stress testing Vaadin applications
While Vaadin-based applications are essentially normal web applications, they have built-in security mechanisms that need to be configured before you can run stress test tools against them.
To help you get started with stress testing your Vaadin application, we wrote detailed instructions in Vaadin Wiki. These should get you on the right track from the beginning and help you ensure your application performance meets the expectations.