Need some help troubleshooting… we are hitting a wall with our JMeter script simulating 500 concurrent calls hitting a simple IVR menu. The Architect flow times out after 15 seconds, returning a 504 Gateway Timeout. We are using the standard WebSocket endpoint. The error log shows ‘connection reset by peer’. We are in the Asia/Singapore region. Is there a known limit on concurrent WebSocket connections per flow instance? Any ideas on how to tune this?
You need to adjust the timeout configuration for your Architect flow, but be aware that the 15-second limit is often a default gateway setting rather than a hard platform limit. When simulating high concurrency like 500 calls, the WebSocket handshake and initial flow execution can exceed this threshold if the flow includes heavy logic or external API calls.
First, check your flow’s timeout settings in the Architect interface. Ensure the “Timeout” property on the Start node is set to a higher value, such as 30 or 60 seconds. This allows the flow to process before the gateway drops the connection.
Second, verify your WebSocket connection settings in your JMeter script. Ensure you are reusing connections where possible and not creating new handshakes for every simulated call. The “connection reset by peer” error often indicates that the server is dropping idle or slow-to-initialize connections.
{
"flowTimeout": 60,
"websocketKeepAlive": true,
"maxConcurrentConnections": 500
}
Warning: Increasing the timeout too much can lead to resource exhaustion on the platform side, especially during load tests. Monitor your CPU and memory usage in the Genesys Cloud admin console.
Also, consider breaking down your flow into smaller, more manageable chunks. If you have complex logic, try to offload it to a separate flow or use async processing where possible. This reduces the load on the initial WebSocket connection and helps prevent timeouts.
Finally, ensure your Asia/Singapore region has sufficient capacity for the load test. If you are hitting regional limits, you may need to distribute the load across multiple regions or use a different testing approach.
Let me know if this helps resolve the issue.