- Environment: Genesys Cloud US1
- Tool: JMeter 5.6
- API Endpoint: /api/v2/recording/jobs
- SDK Version: N/A (Direct HTTP Requests)
- Concurrent Users: 150
- Test Duration: 10 minutes
The JMeter test plan fails almost immediately with HTTP 429 Too Many Requests when attempting to poll the status of screen recording jobs. We are simulating a peak load scenario where 150 agents initiate screen recordings simultaneously. The goal is to validate if the recording job polling mechanism can handle the throughput required for our new compliance module.
The test script follows this pattern:
- POST /api/v2/recording/jobs to start a screen recording.
- Receive the job ID.
- Poll GET /api/v2/recording/jobs/{jobId} every 5 seconds for 2 minutes to check for completion.
The issue occurs at step 3. While the initial POST requests succeed without error, the polling phase triggers a rapid cascade of 429 errors. The response headers indicate:
Retry-After: 2
X-Rate-Limit-Limit: 100
X-Rate-Limit-Remaining: 0
We have implemented a standard Exponential Backoff policy in JMeter using the Custom CSV Data Set Config and JSR223 PostProcessor. The logic checks for status 429 and sleeps for Retry-After * 1000 milliseconds. However, the rate limit seems to be hit globally across the test thread group rather than per-user or per-tenant context, causing the entire batch to stall.
Is there a specific rate limit tier for screen recording job polling that differs from voice recording polling? We noticed voice recording polls (/api/v2/recording/jobs/voice) seem to handle higher concurrency in previous tests. The screen recording endpoint appears much more restrictive.
We need to determine if this is a hard limit we must architect around by increasing the poll interval significantly, or if there is a configuration in Genesys Cloud Admin that allows for higher throughput on recording job status checks. Any insights on the correct polling strategy for screen recordings at scale would be appreciated.