Can’t quite understand why the messaging websocket connections are dropping immediately when concurrency hits around 50 users. We are running a load test using JMeter to simulate concurrent chat sessions against a Genesys Cloud tenant in ap-southeast-1. The setup uses a simple Architect flow with no complex routing, just a direct queue assignment.
At 10-20 threads, everything works fine. The handshake completes, and messages flow. But once we push to 50 concurrent users, the websocket connections start failing with a 1006 error code almost instantly. The logs show the connection is established but then closed by the server without a proper close frame from the client side. We are using the standard REST API to initiate the conversations and then switching to the websocket for the real-time stream.
No 429s are appearing in the initial setup phase, so it does not look like a standard rate limit issue on the REST calls. The websocket URL is being generated correctly with the session token. We have checked the JMeter config and the network stability is fine. Is there a specific limit on concurrent websocket connections per tenant or per region for messaging that we are hitting? Or is this a timeout issue with the initial keepalive? What is the best way to handle websocket reconnection strategies in JMeter for Genesys Cloud messaging under load?
this looks like a load balancer issue. the suggestion above is spot on. in ap-southeast-1, the default websocket idle timeout is too short for high concurrency. add keep_alive to your jmeter sampler. also, verify the architect flow isn’t dropping sessions due to missing maxConcurrentChats limits. check the error logs.
This has the hallmarks of a classic case where the load testing infrastructure is bumping into platform-side concurrency limits rather than a pure networking issue. While the previous suggestions about keep_alive and idle timeouts are valid for general WebSocket stability, hitting a hard drop at exactly 50 concurrent sessions often points to a specific configuration bottleneck in the Digital Engagement settings or the Architect flow itself.
In my experience managing high-volume scheduling and resource allocation, I’ve seen similar “hard caps” when the underlying queue or engagement type isn’t properly configured for burst traffic. The maxConcurrentChats setting mentioned earlier is critical, but it’s often overlooked how it interacts with the specific engagement type’s concurrency limits in the Admin settings.
First, verify the Digital Engagement configuration for the specific chat channel you are testing. There is often a global limit on concurrent chats per queue or per engagement type that defaults to a low number (sometimes 50 or 100) to prevent resource exhaustion. If your JMeter script is hitting this limit, new connections will be rejected immediately, which can manifest as a WebSocket drop if the client doesn’t handle the rejection gracefully.
Second, ensure the Architect flow is not inadvertently creating a bottleneck. If the flow uses a “Wait for Agent” step without a proper timeout or fallback, and the queue is full, the connection might be terminated prematurely. Check the Queue Settings in Admin to ensure the maximum number of concurrent chats is set higher than your test load.
Here is a quick check for the Architect flow configuration:
{
"engagement_type": "chat",
"queue_id": "your_queue_id",
"max_concurrent_chats": 100, // Ensure this exceeds your test load
"timeout_seconds": 300
}
Also, review the System Logs for any “Resource Exhaustion” or “Queue Full” errors at the exact timestamp of the drops. This will confirm if the rejection is happening at the platform level.