Stuck on a recurring issue where WebSocket connections drop unexpectedly when simulating high concurrent SMS traffic through the Conversations API. The environment is Genesys Cloud (US1), and I am using JMeter 5.6.2 to drive the load. The goal is to validate the messaging capacity for a new client, targeting 500 concurrent active messaging sessions.
The setup involves creating a conversation via POST /api/v2/conversations/messaging, followed by sending messages. However, once the concurrency hits around 300 users, the WebSocket connections start failing with a 1006 error code. The logs show the connection closing abruptly without a proper close frame from the server side. This happens even though the API calls for creating the conversations return 201 Created successfully.
I have reviewed the rate limits, and the request volume is well within the documented thresholds for the Conversations API. The issue seems specific to the WebSocket layer handling the real-time updates for these messaging sessions. I suspect it might be related to how the SDK or the client handles reconnection logic under load, but I want to confirm if there is a known limit on concurrent WebSocket connections for messaging specifically.
Here is the relevant JMeter configuration snippet for the WebSocket sampler:
websocket_config:
endpoint: "wss://conversations.us1.genesyscloud.com/api/v2/conversations/messaging/websocket"
auth_token: "${access_token}"
keep_alive: true
reconnect_delay_ms: 500
max_retries: 3
payload_size_kb: 2
The error occurs consistently after the 300-user mark, regardless of the payload size. I have tried increasing the reconnect_delay_ms and reducing the message frequency, but the disconnects persist. Is there a specific configuration in the Architect flow or the integration settings that I might be missing to handle this scale? Any insights on how to stabilize the WebSocket connections during load testing would be appreciated. I am currently blocked on validating the full capacity for the project timeline.