Digital Channel WebSocket 1006 Drop During High Concurrency Load Test

Trying to understand why our WebSocket connections are dropping with code 1006 (Abnormal Closure) when we ramp up concurrent digital sessions in Genesys Cloud. We are running a load test using JMeter 5.6.2 from the ap-southeast-1 region to simulate peak traffic for our messaging channel. The setup involves establishing persistent WebSocket connections to wss://webchat-{orgId}.mypurecloud.com/webchat/v1.

The issue starts appearing when we push beyond 150 concurrent active sessions. Below this threshold, the connections remain stable for the full test duration. However, once we hit 155+ threads, we see a spike in 1006 errors after approximately 45 seconds of inactivity or low-frequency message exchange. The server side does not send a proper close frame; the client simply loses the connection unexpectedly.

We are using the standard WebChat SDK configuration but driving it through custom JMeter WebSocket samplers to bypass browser limitations. The keep-alive ping interval is set to 30 seconds as per best practices. We have verified that the API rate limits for the initial handshake (/api/v2/conversations/webchat) are not being exceeded, as we are well within the 200 req/min cap. The problem seems specific to the persistent connection lifecycle rather than the initial establishment.

Checking the network logs, the TCP connection appears to drop from the server side without a prior HTTP 429 or 401 response. We suspect this might be related to idle timeout handling on the gateway layer when under heavy load, but the documentation is vague on exact timeout values under stress. Genesys Docs on WebChat Limits mentions general capacity but not specific WebSocket stability thresholds.

Has anyone encountered similar instability with WebSocket 1006 errors during high-concurrency messaging tests? Are there specific headers or payload structures we should adjust in the JMeter sampler to maintain connection stability? We are trying to determine if this is a client-side configuration issue or a platform-side resource exhaustion behavior.

The 1006 drop is typically a heartbeat timeout, not a connection limit. Genesys expects a ping within 30 seconds. In JMeter, add a WebSocket Keep-Alive sampler with a 25-second interval. This prevents the server from pruning idle connections during high-concurrency ramps. Check the KeepAliveInterval in your WebSocket config.

Ah, yeah, this is a known issue… The heartbeat suggestion above is correct for idle timeout, but in high-concurrency JMeter tests, 1006 errors often stem from connection churn rather than just ping intervals. When ramping past 150 concurrent sessions, the WebSocket pool in JMeter can exhaust underlying TCP sockets if connections are not properly reused.

The default WebSocketKeepAlive sampler might not be enough if the test plan creates a new connection for every thread. You need to ensure the WebSocket Sampler is configured to reuse the same connection object across iterations. Also, check the Max Connections setting in your HTTP Request Defaults or WebSocket config. If this is left at the default (often 2 or 4), JMeter will drop excess connections immediately, causing the 1006 error on the server side.

Try setting Max Connections to match your thread group size or slightly higher. In the JMeter GUI, go to HTTP Request Defaults → Advanced tab. Set Max connections per host to 150 (or your target concurrency). For the WebSocket sampler, ensure Reuse connection is checked.

Also, monitor the ws:// handshake latency. If the load generator is in ap-southeast-1 and the Genesys edge is far away, latency spikes during the ramp can cause the initial handshake to fail, leading to a quick close. Adding a small delay between thread starts (ramp-up period) can help smooth the connection burst.

Note: Do not forget to clear the JMeter WebSocket cache between test runs. Stale session tokens can cause immediate 1006 closures if the server rejects the upgraded connection due to authentication state mismatch.