- Genesys Cloud Release: R24.12
- Environment: US East (VA)
- Tool: JMeter 5.6.2 with Genesys Cloud REST Sampler
- Concurrent Users: 200 agents simulated
- Data Action Type: Custom Webhook to internal Node.js service
- Timeout Config: 15 seconds in Architect, 30 seconds in JMeter
Can anyone clarify why the Data Action node consistently returns a 504 Gateway Timeout when the concurrency exceeds 150 sessions, even though the backend service is healthy?
The internal Node.js service logs show that all requests are received and processed within 200ms. No errors on the backend side. The issue seems isolated to the Genesys Cloud Data Action execution layer. When I run the same JMeter script with 50 concurrent users, the success rate is 100%. At 200 users, the failure rate jumps to 45%.
The Architect flow is simple: Trigger → Data Action (POST to internal API) → Set Variable → Response. No complex logic. The Data Action is configured with a basic JSON payload. I have increased the timeout in the Architect node to 15 seconds, which is the maximum allowed for standard Data Actions. The JMeter thread group is configured with a ramp-up period of 60 seconds to avoid immediate spikes.
I suspect this might be related to the WebSocket connection pool limits or the internal API gateway rate limiting for outbound Data Actions. The error response from Genesys Cloud is generic: {"message": "Gateway Timeout"}. No specific error code from the internal service is returned because the request never seems to reach it at scale, or the response is dropped.
I have checked the System Health dashboard, and no alerts are active. The CPU and memory usage on the Edge servers (if applicable) seem normal. Is there a known limit on the number of concurrent outbound HTTP requests a single tenant can handle via Data Actions? Or is this a configuration issue with the webhook endpoint itself? I need to hit 500 concurrent sessions for the final load test phase. Any insights on how to tune this or bypass the limit would be appreciated.