Trying to understand why our JMeter script fails when simulating 200 concurrent agents connecting to the Genesys Cloud platform via WebSocket. We are running the load test from a EC2 instance in us-east-1 to minimize latency, using the standard wss://webcache-<tenant>-us-east-1.genesys.cloud endpoint. The test setup involves a Thread Group with 200 threads, a ramp-up period of 60 seconds, and a loop count of infinite to maintain steady state. Initially, all connections establish successfully with a 101 Switching Protocols response. However, after approximately 500 messages per second are sent across the pool, we start seeing random WebSocket closed abnormally: code 1006 errors in the JMeter log. The server does not send a close frame before dropping the connection. We have verified that the keep_alive interval is set to 30 seconds in our JMeter WebSocket sampler configuration, which should be well within the platform’s expected timeout window. Additionally, we are not hitting the documented 100 requests per second rate limit for message ingestion, as our traffic is distributed evenly. The issue seems to correlate with the number of active open connections rather than the message throughput, suggesting a possible limit on concurrent WebSocket sessions per tenant or IP address that is not clearly documented for load testing scenarios. We have checked the Genesys Cloud Admin console for any active circuit breakers or health alerts, but the platform status shows green. Is there a specific configuration in the Architect flow or the Webchat widget settings that we might have missed that enforces a lower concurrency limit? We need to scale this up to 1000 concurrent agents for our capacity planning report, but the current drop rate is around 15% after the first 10 minutes of the test. Any insights on how to tune the connection pooling or identify the root cause of these 1006 errors would be appreciated. We are using Genesys Cloud version 2024-03-12 and JMeter 5.6.2 with the WebSocket plugin.