Trying to understand the rate limiting behavior for screen recording jobs when simulating heavy concurrent traffic. The environment is Genesys Cloud 2024-1, and the load testing tool is JMeter 5.6.2. The goal is to validate system stability under peak load, specifically focusing on the recording ingestion pipeline.
The test script initiates 500 concurrent calls using the softphone SDK. Each call triggers a screen recording job via the /api/v2/recordings/jobs endpoint. The JMeter configuration uses a thread group with 500 threads, a ramp-up period of 60 seconds, and a loop count of 10. The request payload includes standard recording parameters such as recordingType set to screen and mediaTypes including screen.
As the concurrency increases, the API responses begin to degrade. Initially, the requests complete successfully with HTTP 201 Created. However, once the thread count exceeds approximately 200 concurrent requests per minute, the majority of requests return HTTP 429 Too Many Requests. The response headers indicate the rate limit has been exceeded, but the specific limit value is not clearly documented for this endpoint in the current release notes.
{
"apiErrorCode": "too_many_requests",
"message": "Too Many Requests"
}
The issue persists even when implementing exponential backoff in the JMeter script. The backoff strategy reduces the request rate, but the 429 errors still occur intermittently. This suggests that the rate limit might be stricter than the standard API limits or that there is a specific quota for recording job creation during high-concurrency scenarios.
Has anyone encountered similar rate limiting issues with the screen recording API? Are there specific best practices or configuration adjustments in Genesys Cloud that can help mitigate these 429 errors during load testing? The current setup prevents accurate measurement of the recording pipeline’s capacity, which is critical for capacity planning. Any insights into the expected rate limits or workarounds would be appreciated.