Having some config trouble here correctly when pushing concurrent call volumes above 200 sessions through our private BYOC Edge deployment. We are running a load test using JMeter with 500 virtual users attempting to establish WebRTC connections simultaneously. The Genesys Cloud platform handles the signaling, but the media path is routed through our on-prem edge.
The issue manifests as a sudden spike in 503 Service Unavailable errors on the POST /api/v2/webRTC/media endpoint after about 150 successful connections. The JMeter logs show the WebSocket handshake failing with a generic timeout, not a specific Genesys error code. The edge health dashboard shows CPU utilization at only 40%, and memory is stable. Network latency between the load generator and the edge is under 5ms.
We have verified that the API rate limits for the integration user are set to the maximum allowed for our license tier. The max_concurrent_sessions parameter in the edge configuration is set to 1000. Despite this, the connection pool seems to exhaust or drop connections unpredictably. The error pattern is consistent across three separate test runs.
Is there a specific configuration for the BYOC Edge that limits concurrent WebSocket handshakes independently of the media session limit? Or could this be related to the default connection timeout settings in the platform API when interacting with a private edge? We need to scale this to 5000 concurrent sessions for our upcoming peak period. Any insights on tuning the edge settings or JMeter thread groups to avoid this bottleneck would be appreciated. We are using the latest version of the Genesys Cloud SDK for Java (v2.14.0) to handle the signaling logic in our test script.