Quick question about a weird timeout issue we are hitting during load testing. We are running a JMeter script from our Singapore office to simulate a sudden spike in inbound calls. The goal is to see how the Genesys Cloud Architect flow handles 200 concurrent sessions hitting a specific Data Action that calls an external CRM endpoint.
The setup is pretty standard. We have a Voice flow that triggers a Data Action immediately after the initial greeting. The Data Action uses a simple POST request to a mock server hosted on AWS. The mock server is configured to respond instantly with a 200 OK. However, when we ramp up to 150 concurrent users, about 30% of the Data Action executions fail. The Architect flow logs show a 504 Gateway Timeout error for these specific transactions. The JMeter dashboard shows the external API is responding within 50ms, so the bottleneck seems to be inside Genesys Cloud or the connection between the flow and the platform API.
We are using the latest version of the JMeter plugin for WebSockets. The thread group is set to a ramp-up period of 10 seconds. We have tried increasing the timeout setting in the Data Action configuration from the default 10 seconds to 30 seconds, but the 504 errors persist at the same concurrency level. The error message in the flow execution log is generic: “Data Action execution failed due to a timeout.”
Is there a known limit on the number of simultaneous Data Action executions per tenant? We are on the Enterprise tier. We suspect the platform might be queuing these requests and dropping them when the queue fills up, but we cannot find documentation on the exact queue size or behavior. Any insights on how to tune the Architect flow or JMeter config to avoid this? We need to ensure our production system can handle these spikes without dropping calls.