Content
This post is a direct follow up of this
one where I introduced a bit what I did in order to integrate Gatling in SBT and in Play2.
Where this post was more about bits and bytes necessary to accomplish the task, this one will talk about how to use this mess.
Gatling for SBT
Now, that we've a dedicated SBT plugin in hand we can create a sample project that uses it (I already created one
here).
In this new project, we'll need to create a file
plugins.sbt which will contains the reference to the
gatling-sbt-plugin.
Actually, it's the classical way to add a plugin to a SBT project (and the easier and the "semanticest").
We're now prepared to configure our build by using the pieces provided by the plugin.
At the end, we'll be able to write a first test and launch it.
Project Build
First of all, we must create a directory for your project with this basic structure:
After having used everything in your project (don't forget to add the
GatlingTest configuration...) you're so close to
write your first test.
Gatling Conf
This section will cover the other folder
src wherein reside the classical
main and
test folders.
But there is an other one,
gatling-test that is unknown at this stage.
In fact, this folder will be the root for our Gatling tests, holding the
configuration file (I provided a basic one in the sample app) and the
future simulations that you'll write.
The first is dropped in
conf/galing.conf, where the latter is simply
simulations.
Write your first test
At this stage, I'll make an assumption that you either know the Gatling api... Nah, the Gatling DSL is sufficiently self descriptive (otherwise check the
wiki).
As you can see, it's very very easy (
that's why I like Gatling-Tool).
All we had to do, since we're benchmarking
google, is to implemnent the
apply method of a simple scenario within a class (with must have an empty constructor...
a limitation for now) that must extend our custom Simulation
(yeah! I know ... I'll choose another name for it that's why GSimulation is needed).
Note the dummy implementations of the interceptors whose aren't needed here.
This Simulation must be located somewhere under the
simulations folder.
Now, we can launch it and see where are stored the results.
That's enough boy...
Let it shot the server and generate the result.
...
...
Done? ok.
Now, that all bullets have been shot, you can go in this folder
gatling-project/target/gatling-test/result.
See? True! Every run will create a specific folder under this one, named
run-${scenario-name}-time.
Make some jump in it and locate the index.html file, open it in your browser and see the magic happened.
NB: check this page for information about the reports.
So far, so good. But we're writing web apps and we want to stress them... we all know that the google server won't crash (that easy).
Let's move to Play2 (or you can write your own app w/o Play2 using Spray or another Java framework maybe, then mimic the following).
Gatling for Play2
For this part, I also wrote an
application that makes use of the "plugin" introduced in the previous post.
It's quite complicated, not yet polished and might be a good topic for a future post, because I tried to make an application based on
Event Sourcing with some workflows and usages of pure functional structure like
Lens,
Writer,
State,
Monad and so forth.
But let's stick with the actual topic, if you fork the project and browse a bit its build configuration you'll see that it is near from the one we just talked about.
But still that some particularities are presents...
Definition
First of all, since Play2 has its own convention for sources folders (
app,
test under the root) we'll redefine those folders for gatling as well.
In order to do that, we must
adapt the following configuration keys:
Actually, yeah, we've just skipped the "src" folder. Anyway.
So far, so good...
I heard you...
But, do you known that we're already done?
Allez, let's write a test.
Write
If you started from scratch (without forking the sample app) you can now stress test your
index page that will render the default
welcome page defined in Play2.
See the below Gist for that, or its follower for a more complicated one using the app.
Look what I've done Dad!
In the Simulations, all we had to do is to simply declare an available port on which the framework can start the server, and its needed FakeApplication to have access to the routing.
Then when we had to build a request path, we've just had to do the same as in our templates, that is, use the routes object under the controller package. Amazing.
Furthermore, we can also reuse our type checked Form to build our feeder. Waouw.
But, at this stage, there still some boilerplate (parameters). Looser.
Launch
And now, it's time to stress test our server and see how it'd behave on production. (Ok, that's not 100% true, since Gatling is running on the same machine...)
For that, just do the following:
Wait.
Again.
Now, go to you result directory (the path hasn't changed).
Open in your browser and let the shine comes in.
Wrap Up
At this stage, with small and few injuries we can use
Gatling-Tool without having to install or trick stuffs in order to have information about our web app.
This by using either a full SBT application or a Play2 based one.
I know that there still a lot to do, but at least the basic features are there, and I'll enjoy anyone forking it, scrapping it if necessary and let me know.
Last words
I hope you liked these posts, otherwise I'd like to apologize because I did all projects and the blogs on the train, half asleep every morning and evening, back and forth from my actual mission's workplace.
Now I'm gonna sleep in this train...
Oh no, I can't...
I've to write my book now.
