We are building reactive web application on top of akka framework.
Is gatling the right tool for load testing reactive applications.If yes we would like to evaluate Gatling for reactive application, please share the details to get started.
What happens on the server side stays on the server side.
From the client perspective (browser, load test tool or whatever), how you build you server isn’t relevant.
Thanks. I understand your inputs and already aware of this.
Reactive application will do the user request processing asynchronously. The user will get response from the server asynchronously.
Can gatling analyze asynchronous request and responses? If not, any future plan to support?
I am asking this since Gatling is built on top of akka and scala. Gatling team will definitely know the behavior of akka and its asynchronous behavior.
Except for resources and WebSockets, the flow is quite unidirectional: one input => one output pipeline.
WebSockets users would like something more flexible with listeners/callbacks, that’s something we’ll investigate for Gatling 2.1.
Except for resources and WebSockets, the flow is quite unidirectional: one input => one output pipeline.
WebSockets users would like something more flexible with listeners/callbacks
[Prakhyat] I am not able to understand your response totally.
Depending on the level of complexity in your client (callback hell depth), you might not be able to implement exactly the same thing with Gatling, you’ll have to simplify.
I advice you read Gatling’s documentation, play with it a bit, and maybe your opinion of it matches your needs or not.
I will look into documentation. The intent to put this post is to get quick feedback or insights into whether any one has used Gatling for performance testing reactive web applications.
Will gatling support reactive? if no, till when it is expected? that’s all.
Reactive is just a buzz word that Typesafe and al uses to market their technologies.
I’m not saying that’s a bad thing, their technology is great and deserves to become popular.
What I’m saying is that your question “Will gatling support reactive?” doesn’t make more sense than “Will gatling support shiny?”.
Give me a concrete use case and I can tell you if Gatling supports it.
Request reaches reactive server. Response is sent back with status 200.
The received request is processed asynchronously at server side using akka actors. The actors add accounts to DB.
Using web socket server responds to user browser for successful account creation and returns back account number.
With Gatling I want to load test this URL http://my-app/addAccount. I want to check how much time it will take for one request to complete. Later keep on adding load and see performance. Want to get,
At the moment, Gatling has probably the best WebSocket support out there, amongst load test tools.
AFAIK, it’s the only one that can mix regular HTTP and WebSockets, and provide a way to reconciliate state (data/events from multiple websockets and regular HTTP/Ajax running concurrently).
Still, our WebSocket API is in its first version, and we’re planning on improving things for Gatling 2.1.
For example, you can listen to a WebSocket for a given condition until it completes (like listener for a given message from the server), but you can set up only one condition at a time.
Hope I’m being clear.
Then, If your going with the Typesafe stack, and maybe Scala, I think Gatling will perfectly fit in your toolbox.
There’s no notion of “request” and “response” with WebSockets.
WebSocket is a full duplex connection, so there are incoming and outgoing messages, both being not correlated.
For example, you get be receiving a message from the server because you just sent it one, but you could just be receiving a message because of whatever event (like someone else posting a message in the chatroom you’re connected to).
With Gatling WebSocket support, you can:
open a WebSocket
close a WebSocket
be automatically reconnected if the WebSocket crashes for whatever reason
send a message to the server
listen to a websocket, possibly until a given condition completes, either in a blocking way, or a non blocking way