I’ve spent hours trying to figure out why the screen recording api starts returning 429 too many requests errors when our jmeter script hits just 50 concurrent sessions. we are trying to validate the capacity for a new deployment. the environment is genesys cloud us-east-1. we are using the standard rest api endpoint POST /api/v2/analytics/screenrecordings.
our jmeter plan creates a user login, starts a screen recording, waits 60 seconds, and then stops it. this cycle repeats. at 20 concurrent users, the response time is stable around 200ms. but as soon as we increase the thread count to 50, the error rate spikes to 40%. the error message in the response body says rate limit exceeded.
we have checked the organization limits in the admin console. the api rate limit for our org is set to the default tier. i thought the limit was higher. maybe 100 requests per second? but the jmeter dashboard shows we are only hitting about 15 requests per second on average for the recording endpoints.
we are also seeing some latency spikes in the websocket connections for the softphone, but that might be unrelated. the jmeter log shows the 429 errors happening specifically on the start and stop calls, not the get calls.
here is a snippet of our jmeter sampler configuration:
- http request sampler: post /api/v2/analytics/screenrecordings
- body data: json with recording id and status
- concurrent users: 50
- ramp up period: 10 seconds
is there a specific rate limit for screen recording actions that is lower than the general api limit? or is there a way to batch these requests? we need to support at least 500 concurrent agents with screen recording enabled. if the api cannot handle this load, we might need to change our architecture. any help with the rate limit configuration or best practices for load testing this api would be appreciated. we are stuck on this for two days now.