A little background.
Load testing tools generally send a high number of requests against a target host of your choosing. These tools are used to stress test how many requests a service can handle before it becomes unacceptably slow, unresponsive, or even crash a service. So being able to answer the question of
how many users a website/app/service handle before the slow down causes users to turn away is a very, VERY important one. Load testing tools have a variety of mechanisms to calculate the answer. Herein I evaluated Gatling.io's offering.
What makes Gatling Different?
Gatling allows the user (developer/operator) to record a series of actions in the browser of choosing. At the tempo of a real user, multiple steps, form input, reloads; all can be done because the test cases are being created by a real user in a real browser. Use cases can be grouped and executed by virtual user assignment or individually. For the more technically inclined among us Gatling also supports a Scala like domain specific language (DSL). This languages allows for near infinite control on how tests are executed. Perfect for testing auto-scaling policies and load balancing in large cloud based systems. Finally, if you have the budget Gatling offers a ‘Frontline’ service. A SaaS offering that
helps you manage all aspects of performance testing through its interface.
Bonus: Gatling can also render the output using a handful of different chart systems, I only evaluated the high chart offering so YMMV with the visualizations.
Opinionated 15min Crash course
For this demo, we will be stepping through the process as I did to get a basic test case created and executed. The Quick start guide has more details . This is my quick start steps.
Download the project, at the time of writing 2.3.1 was the current.
Unzip the file, I did it into `~/Projects/tools/gatling-charts-highcharts-bundle-2.3.1`
Go into the new directory.
Execute ./bin.recorder.sh, wait, after a few moments a Java application window will be displayed. This is Gatling’s main UI.
Enter a value for
vendor, then provide a class name value.
Save preferences; finally hit
Start!. In a moment the Recorder window appearse. Leave it alone for now.
Next, I started up Firefox and set the proxy settings to use localhost:8000 for all requests.
Visiting a site of my choice (I used this site). You should see some output in the recorder’s
Executed Events panel. This is good, very good.
I moving around the site and recorded some other events.
Once completed I pressed the
stop & save button and the window closes.
As I was done w/ the UI I closed the main window as well.
Back in the terminal the process to execute the recorded is surprisingly straight forward. Executing`./bin/gatling.sh` resulting in the expected package/class name options. Think of these in the same relationship as suite/test in many other tools.
Selecting the correct value and pressing enter a few times I was greeted with the execution steps running.
The test will take as long, if not longer than, than the original recorded process. The waits between steps, the resource loading, the clicks, etc.
At the end of it all Gatling provides a local URL to view the results in a browser with pretty graphs.
This is the really nice part as compared to many other load testing tools.
As a load testing tool Gatling is as simple as it gets; just make sure you have the Java 8 JDK set as the JAVA_HOME env variable. With the recorder and the highly versatile DSL scripting ability, and the straight forward CI/CD integrations, and even the Frontline SaaS offering makes Gatling a serious contender for the load testing step in your Operations/QA/Testing process.
Gatling ONLY works with the Java 8 JDK. You MUST set your systems JAVA_HOME global variable to the JDK 8 java bin directory. Otherwise you get a cryptic message about not being able to find the test classes.
Paul-Henri from Gatling saw the articled and emailed me. The Frontline offering is an on-Premises offering, not SaaS. Thank you for the correction Paul-Henri!
Originally published at David J Eddy.