Does anyone know how to handle Architect flow timeouts when simulating high concurrent call volumes?
I am currently running load tests against a Genesys Cloud Architect flow using JMeter 5.6. The goal is to validate the system’s capacity under peak conditions. We are simulating 500 concurrent inbound calls hitting a specific IVR menu. The flow is relatively simple, with just two levels of navigation and a final transfer to a queue.
The issue occurs when the concurrent thread count exceeds 300. The JMeter test plan uses the Genesys Cloud API to initiate calls via the /api/v2/architect/flows/{flowId}/execute endpoint. We are using the standard SDK configuration for WebSocket connections.
At 300 threads, the response time starts to degrade significantly. By 400 threads, we see a high percentage of failed executions. The error message returned in the JSON response is consistent:
{
“code”: “timeout”,
“message”: “The flow execution timed out waiting for user input or system response.”
}
I have checked the Architect flow settings, and the default timeout for user input is set to 30 seconds, which should be sufficient. The JMeter test is configured to send DTMF tones immediately upon connection to simulate user interaction. However, the timeouts persist.
I suspect this might be related to WebSocket connection limits or API rate limits during the flow execution phase. The environment is a standard Genesys Cloud instance in the US-East region. We are not using BYOC for this test; it is purely API-driven call simulation.
I have tried increasing the JMeter keep-alive interval and adjusting the thread group ramp-up time, but the results remain the same. The error seems to originate from the Architect engine rather than the network layer.
Has anyone encountered similar timeout issues during high-concurrency load tests? Are there specific Architect flow optimizations or API parameters that can help mitigate this? Any insights into how Genesys Cloud handles concurrent flow executions would be appreciated.