How should I properly to handle websocket disconnects when running jmeter tests with 500 concurrent users? the architect flow times out at the third set variable block with 408 errors. increasing timeout did not help. the api logs show successful auth but the voice channel closes abruptly. is there a specific config for load testing in genesys cloud to prevent this?
Check your Architect flow configuration for synchronous actions that might be blocking the execution thread under high concurrency. The 408 timeout at the third Set Variable block suggests a resource contention issue rather than a WebSocket protocol failure. In Genesys Cloud, excessive synchronous API calls or long-running data actions can cause the voice channel to drop if the flow does not complete within the expected SLA window.
Consider moving heavy data processing to asynchronous tasks or using Data Actions with appropriate retry logic. Additionally, verify that your JMeter script is not exceeding the rate limits for the specific endpoints being called. The documentation outlines best practices for load testing flows here: https://developer.genesys.cloud/architect/load-testing-guidelines.
If the issue persists, examine the Conversation Detail view for dropped calls to identify if the drop occurs during the setup phase or after the flow has started executing. This distinction is crucial for determining whether the problem lies in the signaling path or the flow logic itself.
The official documentation states that synchronous API triggers within Architect flows have strict latency limits. When scaling to 500 concurrent users, resource contention often causes the 408 error. Switching to async mode with exponential backoff usually resolves this, as suggested above. Check the platform_api rate limits for your specific org tier too.