It seems that Gatling does not support WebSocket at this moment.
Is there a roadmap for this feature?
I guess this feature is a big advantage for Gatling because many other
test tools still do not have it.
Thanks.
Hi Ngoc,
We’ll probably add websockets support someday, but I can’t tell you when.
My feeling is that we’ll have our hands full with more pressing features (injection profiling, clustering, Scala 2.10 migration, SQL support…) until Q2 2013.
But then… we love contribs 
Cheers,
Stéphane
2012/10/31 Ngoc <ngocdaothanh@gmail.com>
I wrote this for testing one of our WebSocket apps in Gilt:
https://github.com/gilt/gatling-websocket
… if it’s useful, or if you can suggest changes that would make it useful, I’d love to hear back.
Hi Andrew,
Very very cool!
I probably won’t have time to review it in the next 2 weeks (have to prepare my talk for Devoxx, and then… go to Devoxx) but I’ll definitely contact you to see if you could contribute this to Gatling main project.
Just one rapid question: why go for Jetty instead of Netty?
Bravo!
Stéphane
I did a previous JMeter plugin that used Jetty’s WebSocket lib - that’s the only reason.
I’ll take a look at Netty’s and Grizzly’s equivalents to reduce the number of dependencies later in the week.
Also note that AHC supports websockets:
http://jfarcand.wordpress.com/2011/12/21/writing-websocket-clients-using-asynchttpclient
I moved this to AsyncHttpClient; I will need to write something like
the http protocol config to supply the few configurable parameters,
but it's certainly usable without it.
-- Andrew
Hi Andrew,
Very impressive!
I did some comments on your last commit.
Cheers,
Stéphane
I’ve just created this issue:
https://github.com/gilt/gatling-websocket/issues/2
Please help.
Thanks.
I wanted to try out that feature and started by seeing what I can do.
I took this to app : https://github.com/playframework/Play20/tree/master/samples/scala/websocket-chat
and created the following scenario : https://gist.github.com/4354730
Andrew, is this a correct use of the API ?
And currently, we can only send messages, is that right ?
My simulation seems working and it’s already pretty cool.
cheers
Nicolas
That’s about it. The only thing I’d change is to add the optional parameter so the calls to open have a different request name to the calls to sendMessage and close, which are both very fast. In fact, I think I should probably make it the only behaviour that the requests have the names “<socket_name> Open”, “<socket_name> Send” and “<socket_name> Close”, and maybe add an optional flag to disable recording sends and closes in the log. What do you think? It feels similar to how redirects are reported on now.
Yes, currently you can only send. This is about adding checks on received messages: https://github.com/gilt/gatling-websocket/issues/1 - should I move it over to excilys/gatling? I will work on it (and a few more more ideas, hopefully) over the holiday.
I’m now watching the gilt/gatling-websocket … I’ll now follow that discussion.
I actually have two remarks about the DSL :
1/ if we do a basic HTTP query, we do .exec(http(LOG_NAME).get("/"))
But, for the web socket, we currently have to write this .exec(websocket(WEBSOCKET_NAME).open(ws://localhost, LOG_NAME) )
It has been quite confusing for me not to write .exec(websocket(LOG_NAME).open(ws://localhost, WEBSOCKET_NAME) )
Do you see my point ?
2/ I’m not a fan of that open / close thing. I would prefer to come-up with something that has more of the spirit of the “scala-arm” project …
.withWebsocket(“superWebsocket”, “ws://localhost”) { // it will automatically log the “Open superWebsocket” / “Close superWebsocket”
ws1 =>
exec(http(“foo”).get("/"))
.exec(websocket(“say hello”).send(“hello”)(ws1))
}
Would this make sense?
- You can’t do that, as it would tie the structure API to the websocket module. We want to keep the structure API protocol agnostic in order to implement more protocols (SQL, LDAP, JMS…)
True.
So, what about that ?
.with(websocketRessource(“ws://localhost”)) {
…
}
.with(jdbcRessource(“jdbc://…”)) {
…
}
It would mean that we need to introduce a “.with()” element in the core and sort of a “AutoClosable” API.
What do you think ?
This idea is interesting, but I wonder if there's not some redundancy with
ProtocolConfiguration here.
I don’t see what you mean, what kind of redundancy?
Forget about it, that’s off topic here. That’s just that regarding your jdbcResource, you wouldn’t pass the url, as you would configure a DataSource in a JdbcProtocolConfig.
I tried using the Gatling Websockets Addon with Gatling 2. Does the package support Gatling 2 or just Gatling 1?
Thanks.
Sebastian
The WebSocket plugin is for Gatling 1. Most of the functionality has been merged into Gatling, but there isn’t a released milestone containing it yet, unfortunately.
Coming, coming… doing our best…