Hi:
I am using the websocket plugin on the gatling and have some issues with it. Wondering where should I post questions?
Thx
Shawna
Hi,
The Google group is the place for any questions related to Gatling, and that includes Gatling’s WebSockets support 
Cheers,
Pierre
cool.
So this is what I did to call the websocket:
val callWebsocket =
exec(http("${msgbus}/socket.io/1")
.get("${msgbus}/socket.io/1")
.check(status.is(200))
.check(regex("(.+?):").saveAs(“token”))
.check(bodyString.saveAs(“getBodyString”)))
.exec(session =>{
var token = session.getTypedAttributeString
var token2 = session.getTypedAttributeString
println(token2)
println(token)
session
})
.exec(websocket(“socket”)
.open(“wss://realtime-bus.integ.jivehosted.com:443/socket.io/1/websocket/${token}”,“socket_open”))
.exec(websocket(“socket”).sendMessage("${postBody}", “socket_send”))
.pause(10)
.exec(websocket(“socket”).close(“socket_close”))
In the log, I can see the session id is created and handshaked,
ESC[90mdebugESC[39m: socket.io: handshake authorized SjaUdNXMz-eRAO1nkKec
ESC[90mdebugESC[39m: socket.io: setting request GET /socket.io/1/websocket/SjaUdNXMz-eRAO1nkKec
ESC[90mdebugESC[39m: socket.io: set heartbeat interval for client SjaUdNXMz-eRAO1nkKec
ESC[90mdebugESC[39m: socket.io: client authorized for
^[[90mdebug^[[39m: socket.io: set close timeout for client SjaUdNXMz-eRAO1nkKec
^[[90mdebug^[[39m: socket.io: cleared close timeout for client SjaUdNXMz-eRAO1nkKec
^[[90mdebug^[[39m: socket.io: cleared heartbeat timeout for client SjaUdNXMz-eRAO1nkKec
^[[90mdebug^[[39m: socket.io: discarding transport
But seem like the message that I am sending is not there. I am not sure what is going on. Can you give me some start points?
The message that I am sending is a json format like this:
{“to”:“jcint-realtime-bus1-integ.phx1.jivehosted.com:::8451:::nj3UwPMGwOysyncVKEMIOQ”,
“ts”:“2013-08-20T13:21:48Z”,
“type”:“chat”,
“ver”:“1”,
“body”: {
“sender”:“2006”,
“recipients”:[“2006”],
“text”: “heritage opposite EFFECTS ask cover”
},
“id”:“ac73245f-4bc4-4256-9636-8cabb56f4db8”,
“auth”:“3KtwvPm2uI+qL5gsZyJ+OB7Ljb+NeJIIGa6RFVCg4L+csKdyFHWTJPqKWkJ6fcZV0THwbSThOPVUjdbcpVw8EOFzgO7LC/dh78s6SGA4oxXU6sJ36TX3FjCHdMByGaZF0ZNyoIL5pv+dB/RMnk8RSs/NaEn4kQgTq3A2YGM=”}
Where do the logs you pasted come from?
Although I can’t really tell yet, I suspect the problem might be that you are opening the socket, immediately sending a heartbeat, then pausing; shouldn’t the pause be before the heartbeat?
This log comes from socket.io. Which is said to be a wrapper for the pure websocket. In the gatling websocket plugin document, I didn’t see any example how should I pause.
I am referring to this doc to do the exact way they are doing. http://blog.gridinit.com/2012/12/12/testing-socket-io-and-websockets-on-the-grid/
Based on the socket.io documentation the first thing I would do is ensure that the server is listening to the “message” event (bottom of http://socket.io/#how-to-use):
var io = require(‘socket.io’).listen(80);
io.sockets.on(‘connection’, function (socket) {
socket.on(‘message’, function (data) {
console.log(data);
});
});
If you’re already doing that, it might be that socket.io can only handle websocket messages in its own format, so you’ll need to use the Chrome developer tools to examine the websocket in your client app and replicate the entire frame in Gatling.
I am not quite following. Does that mean I can’t use the websocket plugin? When you say replicate the entire frame in gatling, Do you mind elaborate more using some examples if possible?
Thx a lot!
I checked the frame and sent the message the exact format. It seems to be going through. One more question, During the opening, do i need to send the heartbeat from the script often to keep it alive?
Also, When I send some message with the wrong message format, the plugin is not complaining, it still give me OK which is preventing us to use it. Do you have any plans to implement checking the response?
I’ll try to answer both questions.
-
How often do you need to send a heartbeat? This depends on what the recipient of those heartbeats expects. socket.io is a client and server library that provides two-way communications built on WebSocket and other protocols. I can’t find what socket.io’s default heartbeat interval is from the documentation so the best I can suggest is that you run your client application in Chrome for a while and see what the interval appears to be in the developer tools.
-
Sending an incorrect message is not an error. Again, socket.io is a toolkit built on several transport technologies including WebSocket. Gatling has basic support for load testing a WebSocket server - it does not use socket.io. Gatling isn’t really a functional testing tool, so using it to ensure that your server responds correctly to invalid input is outside of Gatling’s scope a bit. Also, the WebSocket support in Gatling 2 (based on the add on for Gatling 1) is really basic for now - it allows you to test that the server can open numerous connections and keep them open, and nothing else. However, given that a few people have asked about load testing command-response type patterns on WebSockets using Gatling I do intend to implement checks on sendMessage that will cause it to expect a response; I don’t have an estimate of when though.
thx for the reply…
For the first one, I checked my chrome, it is around 25 secs.
My another question is how to implement this in gatling?
Basically I need to have an “automatic” process to send the heartbeat every 25 sec. Is there a way to do that in gatling?
I was on vacation for a while, so sorry it took so long to reply.
Since there’s no way currently to test two-way comms across the socket, the simplest thing I can think of is to create a scenario in which each user opens a socket, then enters a loop that pauses for 25 seconds and then sends a heartbeat, and finally closes the socket. That will ensure that the server can maintain the desired number of concurrent sockets. If it drops sockets under load that will show up as failed sendMessage requests; if it starts to take longer and longer to open sockets under load that will show up in the response times for the open requests.