Hey everyone,
I am trying to simulate a high-concurrency scenario for our custom agent desktop integration using JMeter. My goal is to stress-test the Genesys Cloud Platform API, specifically the WebSocket connections for real-time event subscriptions.
I configured my JMeter test plan to open 500 concurrent WebSocket connections to wss://streaming.mypurecloud.com/v2/platform/websocket. I am using the standard bearer token authentication header. The test runs fine for about 200 connections, but once I hit that mark, a significant number of connections start failing immediately with a 503 Service Unavailable error. The response body usually contains a generic JSON error message saying "message": "Service unavailable".
I have checked the Admin UI and confirmed that our organization’s WebSocket connection limit is set to 1000, so I should not be hitting a hard cap yet. I am also aware of the rate limits for the REST API, but I am not sure if there is a specific threshold for WebSocket handshakes per second that I am violating.
My JMeter script uses a simple WebSocketOpen sampler followed by a WebSocketSend sampler to subscribe to the v2.users.{id}.presence topic. I am running this from a single instance in the Asia/Singapore region, but our GC tenant is in us-east-1. Could the latency or the geographic distance be causing timeout issues that manifest as 503s?
Has anyone else encountered this specific error when scaling WebSocket connections with JMeter? Is there a recommended ramp-up time or keep-alive configuration I should adjust in my test plan to avoid these drops? Any insights on the actual handshake limit would be greatly appreciated.
Thanks!
nah, 503 on websocket usually means the auth header is stale or the edge is rate limiting the handshake.
in the .au instance, we hit this when the bearer token expires during the test setup. the websocket connection doesn’t refresh the token automatically like a rest call would.
make sure your jmeter thread group is using a WebSocket Sampler with the Upgrade Request header set to websocket. also, check if you are hitting the rate limit for new connections. genesys cloud has a limit on how many websockets can be opened per second.
try adding a delay between thread starts. if you fire 500 threads at once, the api might reject the bulk of them.
also, double check your endpoint. if you are on the australian instance, it should be wss://api.au2.mypurecloud.com/v2/platform/websocket. using the usw2 endpoint from .au might cause routing issues or timeouts that look like 503s.
we had to split our load into 50 threads with a 100ms ramp-up to keep it stable.
got it. switched to a js pre-processor to fetch a fresh token right before the handshake and the 503s vanished. thanks for pointing out the token expiry issue. weird how the rest calls handle refresh automatically but websockets don’t.
glad it worked. just remember to cache that token if you’re hitting the endpoint hard, or you’ll get rate-limited on the auth side instead.
2 Likes
the 503s usually stem from the edge rejecting stale tokens, which is standard behavior for websocket handshakes. the suggestion about refreshing the token right before the upgrade is correct, but you’ll also need to handle the reconnection logic carefully.
if you’re simulating 500 agents, the default backoff strategy in jmeter might overwhelm the auth endpoint. i’ve seen this when running load tests for our queue analytics dashboard. you should implement an exponential backoff in your js pre-processor to avoid triggering rate limits on /oauth/token.
don’t just retry immediately on failure. the platform will block you faster than you think.
here’s a quick snippet to add jitter to your retry logic in the pre-processor:
var delay = Math.random() * 1000 + 500; // 500-1500ms jitter
Thread.sleep(delay);
this spreads out the auth requests and keeps the handshake success rate high. also, ensure your thread group isn’t spawning all 500 threads at once. use a ramp-up period of at least 60 seconds. the websocket connection pool in jmeter isn’t as forgiving as the rest client.
1 Like