Quick question, has anyone seen this weird error? with the Genesys Cloud analytics API during high-concurrency load testing. We are trying to simulate a dashboard refresh scenario where 200 virtual users simultaneously request interaction data via the /api/v2/analytics/interactions/queries endpoint. The setup uses JMeter 5.6 with a custom WebSocket sampler to maintain persistent connections, mimicking real client behavior. Each thread group is configured with a ramp-up time of 10 seconds to reach 200 active threads. Authentication is handled via OAuth2 client credentials flow, generating a new access token every 10 minutes to avoid expiration issues during the test run. The initial 50 threads connect successfully and start receiving data streams as expected. However, once the concurrent connection count hits approximately 180-190, we start seeing immediate 1006: abnormal closure errors on the WebSocket channel for the remaining threads. The server does not return a standard HTTP 429 or 503 error before dropping the connection. It feels like a hard limit on simultaneous WebSocket subscriptions for this specific endpoint is being enforced at the platform level, but the documentation does not explicitly state a per-user or per-org concurrency cap for analytics queries. We have verified that the API rate limits for standard REST calls are not being exceeded, as we are throttling the query frequency to one request per user per minute. The environment is a production tenant with standard performance tier. We are seeing this behavior consistently across multiple test runs from our Singapore-based load generators. The JMeter logs show the TCP connection is established, the WebSocket handshake completes with a 101 Switching Protocols response, but the socket closes within milliseconds after the subscription message is sent. No error payload is returned in the close frame. We have checked the network traces and there are no firewall drops or proxy issues. The problem seems isolated to the analytics subscription endpoint specifically. Is there a documented limit on concurrent WebSocket subscriptions for /api/v2/analytics/interactions/queries that we are missing? Or could this be a transient issue with the specific region’s API gateway? Any insights on how to structure these requests to avoid hitting this invisible ceiling would be appreciated. We need to validate if our dashboard architecture can handle peak load without these silent failures.
This seems like a classic websocket scaling bottleneck rather than an api limit issue. the /api/v2/analytics/interactions/queries endpoint is designed for batch polling, not persistent streaming. when you push 200 concurrent connections through a single jmeter thread group without proper load balancing or connection pooling, the underlying server-side websocket handler drops connections to protect stability.
try switching to short-lived http requests instead. use the standard rest api with pagination. set the size parameter to 1000 and iterate through pages. this reduces the overhead of maintaining persistent tcp connections. if you absolutely need real-time data, look into the analytics streaming api, but ensure your infrastructure can handle the backpressure. also, check your oauth token expiration. 200 threads might be hitting the refresh endpoint simultaneously, causing token rotation delays that manifest as disconnects.
{
"size": 1000,
"select": ["id", "start_time", "end_time"]
}
adjust your jmeter config to use concurrent thread groups with lower concurrency, say 20 threads with 10 loops. this mimics realistic dashboard behavior better than a sudden spike.