Could use a hand troubleshooting this rate limiting issue we hit while running a load test against the generys cloud platform api. we are using jmeter 5.6.2 to simulate concurrent agent logins and websocket connections for real-time presence updates. the goal is to see how the system handles 500 concurrent websocket connections opening within a 30-second window.
the script works fine up to about 200 concurrent threads. once we push past that, the /api/v2/analytics/eventstreams endpoint starts returning 429 too many requests errors. this happens even though we are using valid oauth tokens and the rate limit headers in the response show we are well below the documented limit for our org tier.
here is the relevant part of the jmeter request:
post /api/v2/analytics/eventstreams
headers:
authorization: bearer <valid_token>
content-type: application/json
accept: application/json
body:
{
"events": ["presence", "conversation"]
}
the error response looks like this:
{
"status": 429,
"code": "too_many_requests",
"message": "rate limit exceeded",
"detail": "you have exceeded the rate limit for this endpoint. please retry after 60 seconds."
}
we have checked the api documentation and the rate limits section, but it is not clear if websocket connections count towards the same pool as rest api calls. also, we are running this from singapore (ap-northeast-1 region) and wondering if there is any regional throttling happening.
has anyone else seen this behavior when ramping up websocket connections? are there specific headers we need to set to avoid being throttled? or is there a different endpoint we should be using for high-concurrency presence updates? any advice on how to structure the jmeter script to avoid hitting these limits would be greatly appreciated. thanks!