WebSocket Connection Drops During High-Concurrency Load Test on BYOC Edge

Voice & Telephony
1

Hi all,

I am running a performance test for our new Bring Your Own Carrier (BYOC) setup. I am using a Genesys Cloud Edge deployed in our private cloud (AWS us-east-1). The goal is to validate the stability of WebSocket connections when we push 500 concurrent inbound calls per second.

My test environment uses JMeter with the WebSocket sampler. I am simulating agents joining their queues and then receiving inbound calls routed through the BYOC edge. Everything works fine up to 200 concurrent connections. However, once I hit 250+ concurrent sessions, I start seeing a high rate of connection drops.

The specific error I see in the JMeter logs is a WebSocket connection closed abnormally with code 1006. On the Genesys Cloud side, the Architect flow shows the calls as “Dropped” after about 2-3 seconds. I have checked the Edge logs, and I see warnings about max_concurrent_connections limits being approached, but I thought the default limit was higher than 500.

Here are my details:

  • Genesys Cloud Version: Current (as of Oct 2023)
  • Edge Version: 2023.10.01
  • JMeter Version: 5.6.2
  • Endpoint: wss://<my-edge-domain>/v2/websocket

I have verified that the OAuth tokens are valid and not expiring during the test. I also checked the network firewall rules, and there are no drops at the load balancer level.

Is there a specific configuration in the Edge settings or the BYOC trunk that I need to adjust to handle this concurrency? I know Edge internals, so any guidance on capacity planning for WebSocket connections would be very helpful. I want to make sure I am not hitting a soft limit before the hard limit.

Thanks for your help.

2

From an AppFoundry partner perspective, seeing WebSocket connection drops at 200 concurrent sessions on a BYOC Edge often points to misconfigured keep-alive intervals rather than hard capacity limits. While 500 calls per second is a significant load, the initial drop suggests the client is terminating idle connections before the Edge expects it, or vice versa.

You should verify the ping and pong settings in your JMeter WebSocket sampler. The Genesys Cloud platform expects periodic heartbeats to maintain state. If your test client sends pings too frequently, you may trigger rate limiting on the control plane. If you send them too infrequently, the Edge will prune the connection for inactivity.

I recommend setting the JMeter WebSocket sampler to send a ping frame every 15 to 20 seconds. Additionally, ensure your JMeter thread group is configured with a “WebSocket Keep-Alive” handler that properly responds to incoming pongs from the Edge. If you are using a custom integration, check that your application logic does not block the event loop during high concurrency, which can delay pong responses and cause the Edge to drop the session.

Also, review your Edge deployment logs in the Genesys Cloud admin console for specific WebSocket close codes. Code 1001 usually indicates the Edge initiated the close due to expected termination, while code 1006 suggests an abnormal closure, often caused by network timeouts or TLS handshake failures between your AWS environment and the Genesys Cloud core. Adjusting the TLS session ticket keys in your AWS load balancer might also help maintain connection persistence across proxy layers.