Stuck on a weird issue with the Conversations Events API during a load test simulating high-volume bot interactions. The goal is to validate the system’s ability to handle 500 concurrent bot-initiated sessions hitting a specific Architect flow that relies heavily on real-time event streaming.
The setup involves JMeter 5.6.2 running in the ap-southeast-1 region. The test plan uses the WebSocket sampler to connect to /v2/analytics/conversations/events?filter=type:bot. Initially, connections are stable. However, as the thread count ramps up past 250 concurrent users, we start seeing a significant number of 1006 abnormal closure codes. The logs show the server closing the connection without a proper 1000 or 1001 status.
We are not hitting the documented rate limits for the REST endpoints, but it feels like there is an implicit limit on concurrent WebSocket subscriptions per tenant or per IP range. The JMeter config includes a 5-second ramp-up phase with a loop count of 10. Each virtual user holds the connection for 60 seconds before disconnecting gracefully.
The error isn’t consistent. Sometimes it fails at 200 users, sometimes at 280. This makes it hard to pinpoint a hard ceiling. We have tried adding a small jitter (random delay between 100ms and 500ms) to the connection attempts, but the dropouts persist. The server-side logs in Genesys Cloud don’t show any corresponding errors, just clean disconnects.
Is there a known limit on concurrent event stream subscriptions for bot sessions? We are using the standard developer sandbox environment for this testing. Any insights on how to tune the JMeter WebSocket sampler or if there is a configuration setting in Architect to increase the event stream capacity would be appreciated. We need to ensure the analytics pipeline can handle the load without dropping events.
Thanks for the help.