How should I properly to handle Data Action timeouts when running a high-concurrency load test against Genesys Cloud?
Running a load test from Asia/Singapore using JMeter 5.6.2. The goal is to simulate 200 concurrent users triggering a specific Data Action via the Architect API. The Data Action is designed to fetch user details from an external REST service and return them to the flow.
At low concurrency (50 users), everything works fine. Response times are under 200ms. However, when scaling to 150+ concurrent threads, the Data Action starts failing with 504 Gateway Timeout errors. The external REST service is healthy and can handle the load independently (verified with separate load tests). The issue seems to be on the Genesys Cloud side or within the Data Action execution context.
Key details:
- API Endpoint:
POST /api/v2/architect/flows/run - JMeter Config: HTTP Request sampler with JSON body, 200 threads, ramp-up 10s, loop count 10.
- Data Action Type: REST API
- Timeout setting in Data Action:
5000ms - Genesys Cloud Organization:
US-Eastregion
The JMeter logs show that the request to Genesys Cloud is successful (200 OK), but the response body contains an error indicating the Data Action timed out. The external service logs show that all requests were processed successfully within 100ms. This suggests that the bottleneck is not the external service but perhaps how Genesys Cloud manages concurrent Data Action executions or WebSocket connections for the flow runner.
Is there a known limit on concurrent Data Action executions per organization? Or is there a specific configuration in the Data Action or the Architect flow that needs adjustment to handle higher concurrency? Any advice on how to optimize this setup for load testing would be appreciated. Currently, the load test is failing at 150 users due to these timeouts, which is well below the expected capacity.