Trying to understand why our JMeter load test suite is hitting a wall with WebSocket handshake failures when simulating concurrent WebRTC softphone connections against the Genesys Cloud platform. We are running these tests from our Singapore office, targeting the mypurecloud.com endpoint. The goal is to validate connection stability under peak load conditions before our next major release. Here is the current environment setup:
- Genesys Cloud Region: mypurecloud.com (Singapore)
- Testing Tool: JMeter 5.6.2 with WebSocket plugin
- SDK: PureCloud Platform Web SDK v3.12.0
- Concurrent Users: Scaling from 100 to 500 virtual users
- Test Duration: 10 minutes per ramp-up stage
The issue manifests specifically when the concurrent user count exceeds 300. Initially, connections establish successfully, and audio streams are bidirectional. However, as the load increases, a significant portion of the WebSocket connections fail during the initial handshake phase. The error logs in JMeter show a 1006 Abnormal Closure immediately after the HTTP upgrade request returns a 101 Switching Protocols status. This suggests the server is accepting the connection but then dropping it unexpectedly.
We have verified that the OAuth tokens are valid and have sufficient scope for webRTC:connect. Rate limiting does not seem to be the culprit here, as we are well within the documented API limits for WebSocket connections per tenant. The failure rate spikes consistently around the 300-user mark, regardless of the ramp-up speed. We have also tried adjusting the keep-alive intervals in the JMeter WebSocket sampler, but that did not mitigate the issue.
Is there a specific configuration in Genesys Cloud that limits the number of concurrent WebRTC sessions per IP or per tenant that we might be missing? Are there known thresholds for WebSocket connections that could be causing these abrupt closures? We need to ensure our load testing methodology is accurate and not hitting an artificial ceiling.