Could someone explain the behavior of WebSocket disconnections when simulating high-concurrency digital messaging traffic in Genesys Cloud? We are conducting a capacity validation for a new omnichannel deployment in the US-East region. The test involves a JMeter script generating 5,000 concurrent users initiating digital sessions via the REST API. At approximately 70% load, the system returns HTTP 504 Gateway Timeout errors on the /api/v2/analytics/conversations/events endpoint. The Architect flow includes a simple Get Customer Info data action followed by a Bot Handoff. Network latency is stable, and no firewall drops are observed. The issue persists across multiple test runs, suggesting a potential bottleneck in the WebSocket connection pool or the underlying data action execution engine. We have verified that the API rate limits are not being exceeded, as the requests are spaced evenly. However, the timeout errors increase proportionally with the concurrent session count. This behavior is unexpected given the documented scalability of the Genesys Cloud platform. We need to understand if this is a known limitation of the digital messaging channel under heavy load or if there is a misconfiguration in our Architect flow or JMeter script. Any insights into the root cause or recommended tuning parameters would be appreciated.
It’s worth reviewing at the WebSocket keep-alive settings in your JMeter script. Zendesk handled bursts differently, so Genesys Cloud often drops stale connections faster during high-concurrency tests.