Jmeter STOMP test (WebSocket Samplers)

This post was migrated from Tistory. You can find the original here.

Jmeter STOMP test (WebSocket Samplers)

Install the JMeter Plugins Manager, then install “WebSocket Samplers by Peter Doornbosch.”

You can write Java syntax in a BeanShell Sampler.

In Java, if you want to put a special character (a double quote) inside a String, you need to escape it with a backslash. So for STOMP_SEND, { "type" : "talk" } is written as { \\"type\\":\\"talk\\" }.

(It’s actually a single backslash, but writing it as a single backslash triggered a “structured data that couldn’t be parsed” issue in Google Search Console, so it’s shown doubled here.)

For the STOMP frame format, see the previous post: Stomp protocol

A variable set with vars.put("a", "~~") in a BeanShell can be used in a Sampler as ${a}.

The WebSocket Sampler has a “WebSocket Open Connection” sampler, but if you don’t separately send a STOMP CONNECT frame, you can’t receive STOMP response frames.

(The WebSocket Single Read Sampler times out.)

For client frame commands (CONNECT, SUBSCRIBE, SEND, DISCONNECT, etc.), write the syntax in a BeanShell and send it with a Single Write Sampler.

After sending the CONNECT frame, select “existing connection.”

Loop is under Logic Controller -> Loop Controller, where you can set the number of iterations.

Counter is under Config Element -> Counter, and lets you bind a variable to the repeated sampler’s name.

(It sends a SEND to the subscribed channel.)

With the setup above, if you set the loop count to 20, the samplers run in sequence, so all 20 SENDs run before the 20 READs. This raised two questions:

- If you don’t READ right after a SEND, does the response frame get lost?

- If it isn’t lost, does READ receive the frames in order?

As it turns out, first, the response frames aren’t lost even if you don’t READ them immediately, and second, READ does not receive them in order. For example:

read_4’s response data = {id: 57503, ~~}

read_5’s response data = {id: 57502, ~~}

read_7’s response data = {id: 57501, ~~}

So my guess is that the Spring STOMP server buffers a certain number of response frames as long as the client hasn’t disconnected, and hands out the buffered responses using some order-independent algorithm.

The STOMP server doesn’t close the connection immediately upon receiving DISCONNECT — it sends one last response frame first.

If a receipt header was specified in the DISCONNECT frame, you get a RECEIPT frame back,

and if no receipt header was specified, you get an ERROR frame back.