Running a load test scenario with JMeter to simulate 500 concurrent agents logging in and initiating calls via the WebRTC softphone. The environment is Genesys Cloud US1, using the latest WebRTC SDK (v5.12.0).
The issue occurs when concurrent login attempts exceed 200. The WebSocket connection to wss://api.mypurecloud.com/websocket fails with a 503 Service Unavailable error. This happens specifically during the initial handshake phase, before the call is even placed. The error logs show:
{
"error": {
"code": 503,
"message": "Service Unavailable",
"details": "WebSocket handshake failed due to high load on signaling server"
}
}
The JMeter script uses a ramp-up period of 60 seconds to reach 500 users. Each user performs a login, then attempts to open a softphone session. The API calls for authentication (/api/v2/users/me) succeed, but the subsequent WebSocket upgrade fails.
Has anyone encountered similar issues during high-concurrency softphone tests? Are there specific rate limits or connection caps for WebSocket signaling that differ from standard API rate limits?
The current configuration uses the default WebRTC settings in Architect. No custom BYOC trunks are involved; this is purely softphone-to-softphone testing. The goal is to determine the maximum concurrent agent capacity before signaling instability occurs.
Any insights on how to tune the softphone settings or handle the 503 errors gracefully in the load test script? Also, is there a way to increase the WebSocket connection limit per tenant for testing purposes?
Looking for best practices to stabilize the signaling layer under high load. The current setup causes a cascade failure where subsequent login attempts also fail due to resource exhaustion on the signaling server.