I’ve spent hours trying to figure out why the Script step inside my Genesys Cloud Architect flow is timing out with HTTP 504 errors when I simulate concurrent agent interactions via JMeter.
The environment is Genesys Cloud US1. We are using JMeter 5.6.2 to simulate 50 concurrent agents initiating calls that trigger a specific flow. This flow contains a simple ‘Play Prompt’ action followed immediately by a ‘Collect Input’ action from a pre-configured Script object (ID: script_abc123). The script itself is very short, just a 10-second greeting.
When the concurrency is low (10 threads), everything works fine. The WebSocket connection establishes, and the media handshake completes successfully. However, as soon as I ramp up to 50 concurrent threads, the Script step fails to render the audio content for about 60% of the interactions. The error logged in the Genesys Cloud diagnostic report is SCRIPT_RENDER_TIMEOUT. The flow then falls back to the default error handling path.
I have checked the API rate limits for the /api/v2/architect/flows endpoint, and we are well within the limits. The issue seems specific to the media delivery pipeline during the script rendering phase. I am using the WebRTC SDK v3.3.0 in my test harness. The WebSocket connections are stable, but the actual audio stream from the script engine seems to drop or delay significantly under load.
Is there a known limit on how many script instances can be rendered simultaneously by the Genesys Cloud media server? I have tried increasing the JMeter think time, but that does not resolve the 504s. The error occurs consistently at the same concurrency threshold. I need to understand if this is a configuration issue in the flow or a platform limitation for script playback at scale. Any insights on optimizing script delivery for high-throughput load tests would be appreciated.