Testing WebSockets with JMeter

WebSocket load testing is fundamentally different from HTTP load testing: connections are long-lived and stateful, messages flow in both directions independently of a request/response cycle, and “throughput” means something different (messages/second over persistent connections, not requests/second with connection setup/teardown each time).

JMeter doesn’t support WebSocket natively — you need a plugin

The most common addition is the WebSocket Samplers plugin (by Peter Doornbosch, distributed via the Plugins Manager covered earlier in this series). It adds samplers for opening a connection, sending a message, and reading a response, designed to work within JMeter’s existing Thread Group/Sampler model despite WebSocket’s different connection lifecycle.

The basic test structure

1. Open Connection sampler — establishes the WebSocket handshake, held open for the thread’s lifetime (or until explicitly closed).
2. Single Write / Single Read Response samplers — send a message and read a reply, repeated as many times as your test scenario needs within the thread’s loop.
3. Close Connection sampler — explicitly closes the connection at the end of the flow, important for cleanly releasing server-side resources rather than letting connections linger until timeout.

Modeling realistic message patterns

Real WebSocket usage is rarely simple request/reply — servers often push messages unprompted (price updates, chat messages, notifications) independent of client sends. The WebSocket Samplers plugin’s read operations can be configured with timeouts and matching rules to handle asynchronous, unprompted messages rather than assuming a strict one-message-out, one-message-in pattern.

What to actually measure

• Connection establishment time — handshake latency, which matters a lot if your use case involves frequent reconnects (mobile clients on flaky networks).
• Message round-trip latency — time from send to corresponding response, the WebSocket equivalent of HTTP response time.
• Concurrent connection capacity — how many simultaneous open connections the server can sustain before resource exhaustion (file descriptors, memory per connection) becomes the limit — often the more interesting capacity question for WebSocket-heavy systems than per-message latency.
• Message throughput under sustained connections — messages/second across all open connections, which behaves differently than HTTP throughput since there’s no per-message connection overhead once established.

A capacity-planning consideration specific to WebSockets

Each open WebSocket connection typically holds server-side resources (a thread, a coroutine, a file descriptor, some memory) for its entire lifetime, not just per-request. A server that handles HTTP requests fine at high concurrency can hit a much lower ceiling on simultaneous open WebSocket connections — this is usually the more important number to find via load testing than per-message latency alone.

Alternatives to JMeter for WebSocket-heavy testing

k6 has built-in WebSocket support without needing a third-party plugin, and is often a more natural fit for WebSocket-centric testing if your team doesn’t already have JMeter investment specifically for this use case — worth evaluating directly against the plugin-based JMeter approach if WebSocket load testing is a primary, ongoing need rather than an occasional addition to a mostly-HTTP test suite.

Takeaway: WebSocket load testing should target connection capacity and message latency as separate, equally important questions — and in JMeter specifically, it requires the WebSocket Samplers plugin since there’s no built-in support.