WebChat SDK 2.5.0 WebSocket handshake fails under JMeter load at 500 concurrent users

General Discussion
1

Can anyone explain why the WebChat SDK starts dropping connections when we push concurrent users past 500 in our Singapore staging environment? We are trying to validate platform stability for a new client migration.

Environment Specs:

  • Region: Singapore (ap-southeast-1)
  • SDK: Genesys WebChat SDK v2.5.0
  • Load Tool: JMeter 5.6.2 running on EC2 t3.large instance
  • Target: /api/v2/conversations/messaging and WebSocket endpoints
  • Thread Count: 500 concurrent threads with 10s ramp-up
  • Rate Limit Config: 100 req/sec per IP

Issue Details:
When the thread count stays below 300, the WebSocket handshake (101 Switching Protocols) completes successfully for all sessions. The JMeter listener shows green responses with average latency around 120ms. Once we hit 450+ threads, we start seeing a mix of errors:

  1. HTTP 429 Too Many Requests: This appears first, which is expected given the rate limits. We have added exponential backoff in the JMeter script to handle this.
  2. WebSocket Connection Refused (1006): After the initial burst of 429s, the subsequent connection attempts fail entirely with a 1006 code. The browser console (simulated via JMeter HTTP Request samplers for the handshake) shows the connection is closed by the peer immediately.
  3. Timeout Errors: Some requests hang for 30s before failing with a socket timeout.

We have verified that the service account has the necessary messaging:write and conversations:write scopes. The issue does not seem to be related to API quota exhaustion alone, as the 1006 errors persist even after throttling the initial burst to 50 req/sec. It feels like the WebSocket gateway is rejecting new connections once the active session count hits a specific threshold.

Is there a known limit on simultaneous WebSocket connections per organization in the Singapore region? Or is this a configuration issue within the Architect flow for the digital channel? We are using the default out-of-the-box messaging flow for testing. Any insights on how to tune the load test to bypass this, or if this indicates a platform-side capacity cap, would be appreciated.