JMeter WebSockets

What are Websockets? #

WebSocket are a bidirectional and persistent communication protocol between a client and server, although based on the TCP protocol, information exchange is carried out asynchronously, which is more similar to a non-oriented connection model like UDP. WebSockets were introduced as part of HTML 5 updates and can use ports 80 and 443 for secure or insecure communication:

1. port 80 for ws://
2. port 443 for wss://

Communication begins through a negotiation and exchange of information that can be in the form of HTTP or HTTPS to WS or WSS, the main difference between HTTP and WS is that after the transfer of information between the client and server HTTP closes the connection and WS keeps it open for sending updates.

Below is an example of a client request and server response: #

GET /chat HTTP/1.1
Host: chatserver.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: c2FtcGxlZGF0YQ==
Sec-WebSocket-Origin: http://chatserver.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Example of the server’s HTTP response to change the protocol to WS #

HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: ek8sYU8WRgY4WUU=
Sec-WebSocket-Protocol: chat

What are Websockets for? #

Websockets are primarily used for asynchronous messaging and there is no better example of this than chat applications, although they have multiple uses in SPAs (Single-page application). The communication via chat is asynchronous because we do not know when the client or server will respond to our message. This also applies to chatbots, especially if your intention is to perform end-to-end testing. Such type of testing should not be confused with ML (Machine Learning) tests, which are conducted using models of chatbots. Websockets establish a single channel or port for transmitting messages or updates that can be sent indistinctly between both actors at any time in the moment, creating a sense of real-time communication. The communication is not open indefinitely; there is a maximum waiting time after which if no updates are available, the connection is terminated.

How to test Websockets? #

Websockets can be tested with JMeter using add-ons, and we have two options:

• WebSocket Sampler by Maciej Zaleski

  

• WebSocket Samplers by Peter Doornbosch

  

Let’s start with the addition of Maciej, which I believe is an excellent addition for conducting load and stress tests. Although it may be a little oxidized, there are things we need to consider before starting the test. When sending messages through the medium, it is very likely that the response will arrive almost instantly or slightly late, even receiving two responses within a short period of time. This is due to how JMeter and its engine are built in a synchronous manner, making it difficult to measure precise response times. However, there are other tools that can perform this task better, which we will cover in the conclusions.

Websockets - Terminology #

Server Name or IP: The name of the server or IP address of the server.
Port Number: The port number used, can be 80 or 443 depending on whether it is secure or not.
Connection Timeout: Maximum value in milliseconds for establishing a connection.
Response/Read Timeout: Maximum value in milliseconds for reading or receiving a response.
Protocol: Communication protocol, can be WS or WSS.

Websockets Maciej’s #

Implementation: Only available in RFC6455 (v13) as the latest standard for the protocol.
Streaming Connection: Indicates whether the connection is reused or terminated after using the channel.
Request Data: Text or binary messages that will be sent to the server.
Response Pattern: The pattern with which we can conclude the message.
Close Connection Pattern: The pattern with which we can conclude the connection.
Message Backlog: Defines the maximum number of messages that can be stored before closing the reader.

1.- Install the add-on and restart #

First, we need to install Maciej Zaleski’s WebSocket add-on developed by him from the JMeter Add-ons Manager. Although it is also available in its Github site as a JAR file, it is preferable to use the manager for installing the appropriate dependencies. Once the add-on is installed, we will restart JMeter and validate that the WebSocket sampler is available within the Sampler area.

2.- Configure the reader #

Once the reader is added, we will proceed to configure the necessary information to establish communication. For this purpose, we will use the test site websocket.org, which must have the following information:

Server Name or IP: echo.websocket.org
Port Number: 80
Connection Timeout: 500 ms
Response Timeout: 2000 ms
Protocol: ws
Parameters: encoding=text
Request Data Hello

3.- Validate the Response #

After configuring the WebSocket mule, we need to test that it works. We need to add a result tree listener to see the server’s response, which is a simple echo local that will respond with whatever you send it. If your script didn’t work as expected, here is a link to an example.

Websockets Peter’s #

Open WebSocket Connection: Establish a connection using WS or WSS protocols.
Ping/Pong Messages: Send messages to keep the communication alive.
Request-Response Sampler: Send or receive text or binary data.
Single Write Sampler: Send information in text or binary format.
Single Read Sampler: Receive information in text or binary format.
Close Connection: Close the communication channel.

1.- Install the add-on and restart #

Install the WebSocket add-on developed by Peter Doornbosch from JMeter’s Add-ons manager, although it is also available as a JAR in its Bitbucket site. It is preferable to use the Add-ons manager for installing the required dependencies. Once the add-on is installed, restart JMeter and validate that the WebSocket mappers are available within the Mappers area.

2.- Configure #

This addition is different from the previous one because it requires a set of mouses to establish communication, maintain it, send information, and finally close the channel. To start, we must place a “WebSocket Open Connection” to initiate communication with the following information:

Server Name or IP: echo.websocket.org
Port Number: 80
Connection Timeout: 500 ms
Read Timeout: 2000 ms
Protocol: ws

After configuring the connection module, we must use the “Single Write WebSocket Sampler” to send information to the channel. We should always enable the existing connection that is the first radio button.

Hello

The following should be added: “WebSocket Single Read Sampler” to read information from the channel. Similarly, we must select the option of using an existing connection.

Also we must add the “WebSocket Ping/Pong” to keep the communication channel open, as well as select the option of using an existing connection.

To complete this, we must add the “WebSocket Close” to close the channel and end the communication.

3.- Try It Out #

After configuring the WebSocket reader, we need to test that it works. We need to add a Result Tree Listener to see the server’s response, which is a simple echo locally that will respond with whatever you send. If your Script didn’t work as expected, here is a link to an example.

Is JMeter a good choice for testing WebSockets? #

The answer isn’t straightforward, but I believe it can do the job quite well if your goal is simply to load test the system and measure performance. If you need precise timing of response times, it might perform reasonably well with patterns for responses or closing the connection, which is also important when optimizing resources. Generally, JMeter is a good choice, but depends heavily on the scope of the test. It’s not JMeter’s strong suit in testing WebSockets, as it’s a synchronous tool that limits its perspective somewhat.

Conclusion #

JMeter is a valid option for this task as well. Correlation and token authenticity can be sent through the channel. In short, practically any file or data can be transmitted since it also supports binary transfer. However, in the same way I have tried to transmit in my previous publications, JMeter is not the best option for these types of tests; there are other tools like Gatling, Artillery or K6 that have been built with asynchronous engines which are better for such tasks. Also, for scaling, since it is asynchronous sending of requests, many more can be sent without keeping threads waiting for the response, but this also involves closely monitoring resources like network or memory, as easily overloading generators of load and this benefit could turn into a nightmare.