Is it possible to maintain stable WebSocket connections when pushing concurrent session counts beyond 50 in a load test targeting the /v2/conversations/messaging endpoint? We are running a JMeter script from our Singapore office (ap-southeast-1) to simulate a spike in messaging traffic. The test creates 100 virtual users, each initiating a chat session and sending 5 messages over 30 seconds. The first 40-45 connections establish successfully, but after that, we start seeing intermittent 1006 abnormal closure errors in the JMeter logs. The Genesys Cloud API returns a 200 OK for the initial conversation creation, but the WebSocket handshake seems to drop shortly after. We have configured the JMeter WebSocket sampler to handle ping/pong frames, and the connection timeout is set to 30 seconds. The issue appears consistently when the concurrent user count crosses the 45-user threshold. We are using the latest version of the JMeter WebSocket plugin and have verified that our network firewall allows outbound traffic on port 443. The error does not occur with lower concurrency levels, suggesting a potential limit on the number of active WebSocket connections per tenant or API key. We have also tried staggering the start times of the virtual users to reduce the initial burst, but the drops still occur once the steady-state concurrency reaches 50. The logs show no specific error code from Genesys Cloud, just the abrupt closure of the WebSocket stream. We are unsure if this is a client-side configuration issue or a platform-side limitation on concurrent WebSocket sessions for messaging flows. Any insights into the expected connection limits or best practices for handling high-concurrency WebSocket tests would be appreciated.