BYOC Edge WebSocket Dropouts with JMeter 5.6 at 500 Concurrent Sessions

I can’t seem to figure out why the Genesys Cloud BYOC edge instance starts dropping WebSocket connections when the load test reaches 500 concurrent sessions using JMeter 5.6. The setup is running in the Singapore region, targeting a specific BYOC edge URL configured for WebRTC traffic. The JMeter script uses the HTTP Request Sampler with WebSocket support enabled, initiating connections to the /v1/conversations endpoint. Everything works smoothly up to 300 concurrent users. The API response times remain under 200ms, and the connection pool in JMeter is configured to handle 1000 connections with a keep-alive timeout of 30 seconds.

Context:
The load test is designed to simulate a peak call volume scenario for a contact center deployment. The JMeter configuration includes a Thread Group with 500 threads, a ramp-up period of 60 seconds, and a loop count of 1. Each thread performs a WebSocket handshake, sends a series of JSON payloads representing call events, and then closes the connection after 30 seconds. The BYOC edge is provisioned with sufficient capacity, and the Genesys Cloud dashboard shows no alerts regarding resource exhaustion or edge health issues. The network latency between the JMeter server and the BYOC edge is consistently below 50ms. The JMeter log files show that the WebSocket connections are being established successfully, but the connections are being terminated unexpectedly by the server after sending the initial batch of events.

Question:
Is there a known limit on the number of concurrent WebSocket connections per BYOC edge instance that might be causing these dropouts? The error logs in JMeter indicate a “Connection reset by peer” error after the handshake is completed. The Genesys Cloud API documentation mentions rate limits for REST API calls, but there is no clear information regarding WebSocket connection limits for BYOC edges. Could this be a timeout issue with the JMeter WebSocket implementation, or is the BYOC edge actively rejecting the connections due to a hidden concurrency threshold? Any insights into configuring JMeter to handle this load or identifying the root cause of the connection resets would be appreciated. The test environment is isolated, and no other traffic is hitting the edge during the test.

The documentation actually says to implement an exponential backoff retry within the JMeter script rather than relying on simple reconnection, as this keeps the state management self-contained during high concurrency spikes.

Note: Verify that your BYOC edge configuration supports the specific WebSocket frame size limits for the Singapore region.

{
 "retry": {
 "strategy": "exponential_backoff",
 "max_retries": 3,
 "initial_interval_ms": 1000
 }
}

Have you tried configuring this retry logic in your JMeter script? The Singapore region enforces strict WebSocket frame limits. Without backoff, you risk hitting those thresholds and triggering connection drops. Check the BYOC edge docs for specific frame size constraints.

Pretty sure the issue isn’t just the retry logic but how jmeter handles the connection pool during the spike. when you hit 500 concurrent sessions, the default http client settings in jmeter can exhaust the socket connections before the websocket handshake completes. this causes the byoc edge to see incomplete requests and drop them.

try adding a “keep alive” header explicitly in the http request defaults. also, check the thread group settings. if you are ramping up too fast, the api rate limiter kicks in before the websocket even establishes. a constant timer of 500ms between iterations helped in my last test with 400 users.

<elementProp name="HTTPsampler.Arguments" elementType="Arguments">
 <collectionProp name="Arguments.arguments">
 <elementProp name="Connection" elementType="HTTPArgument">
 <stringProp name="Argument.value">keep-alive</stringProp>
 </elementProp>
 </collectionProp>
</elementProp>

the singapore region has stricter timeouts for idle connections, so keeping the pipeline active is key.