Improve Your WebSocket Application Performance

Improve Your WebSocket Application Performance

Writing a chat application with popular web applications has traditionally been very hard. It involves polling the server for changes, keeping track of timestamps, and it’s a lot slower than it should be. In this post we’ll walk through how to improve your WebSocket application performance.

Socket.io

Sockets have traditionally been the solution around which most realtime chat systems are architected.

Socket.io is a JavaScript library for realtime web applications. It enables realtime, bi-directional communication between web clients and server.

Besides chat applications, socket.io is the best choice for gaming applications. The benefit of using socket.io is the fact that it ties into Node.js seamlessly. When coupled with Express on connection, it can serve the client-side includes, game files, and data, making the integration clean and easy.

Read more about JMeter WebSockets.

Example

For this post we will share an example about connecting to websocket and joining the room.

Socket.io / Engine.io has its own protocol that it uses on top of the ws connection. JMeter doesn’t support WebSocket testing naturally. So first we need to install the WebSocket Sampler plugin. Follow these steps:

– Run JMeter, click Options → Plugin Manager
– In the “Available plugins” section check the Websocket sampler by Maciej Zaleski, then click “Apply Changes and Restart JMeter”.

Also, in some circumstances, JMeter’s “Recording Controller” might not record all required transactions. But thanks to “Chrome Dev tools” we can capture which requests are needed and simulate these requests through JMeter.

After completing the installation we can record our application.

Recording the Application

Our example site is https://socket-io-chat.now.sh/. JMeter’s Recording Controller can capture some requests. However, for connecting to a socket server and emitting data, we have to use “Chrome dev tools” for understanding which data we should simulate. After capturing the beginning requests our test plan is simply:

Before focusing on the Socket connection and sending the data to it, we have to handle the “sid” parameter. First, the “sid” parameter occurs in the second request’s response. So we need to capture this variable and use it for the next request. As you see below, when the request is sent, the response contains the “sid” parameter.

In order to establish the correlation, I created the following Regular Expression Extractor.

After correlation is done, we can pass our “sid” parameter like below:

After completing the correlation operations, we should be able to add the WebSocketSampler. However, we must know how we communicate with the websocket server. As I mentioned before, JMeter can’t record these communications, so we should use Chrome dev tools for this. When we inspect the request to send data to the server, we see that we have to use this syntax: 42[“add user”,”username”].

We need to simulate our WebSocketSampler just as above.

The crucial and tricky part before sending the join the room command is to first send a command of 5. This is an upgrade command. You should refer to the documents below for understanding the protocols:

https://github.com/socketio/engine.io-protocol

After sending 5, the next WebSocket Sampler configuration is below. We can then send the join the room command as seen below:

After the configuration is completed, we can run our scripts and look at the response. We successfully connected to the socket and emitted data.

We can now run load tests on RedLine13 across multiple regions.

  • Enabling Web Sockets: You don’t need to include all the dependencies and plugins, just use the WebSocket checkbox and RedLine13 will include the dependency automatically.

Screen Shot 2016-01-21 at 12.23.42 AM