The beautiful part is that you don't need to know the limit, as long as you handle rate limit responses - https://developer.atlassian.com/cloud/jira/platform/rate-limiting
e.g. by setting a timeout for X seconds when you do hit rate limit, and then re-try the request; this is the most simple way to do it, albeit it's far from perfect since it can create "spikes" (ton of requests hit at once, then timeout, then hit Jira with another brick later). Personally, if I know I'm about to end up doing a lot of requests, I implement my own "rate limit" within the script to only send X amount of requests per second. That way, I do my best not to hit the rate limit cap at all, but if I do then I let it sleep for a few seconds before picking up again.
Concurrency of course complicates that quite a bit, but same principle.
If you're on Cloud there really doesn't seem to be a limit judging by https://community.atlassian.com/t5/Jira-questions/Are-there-any-API-Rate-limits-for-Jira-Cloud/qaq-p/1635241 and https://jira.atlassian.com/browse/JRACLOUD-41876, but you should still consider not doing so many requests all at once since it very well could cause an outage by consuming too many resources for all of the users.
I'm not sure what it is that you're doing, but sending 2000 requests for a jql search does not sound like an optimal approach, more of a brute force one, especially if you intend on doing that every 30 minutes. This is far beyond too much to be considered a good approach.
I can tell you that if I saw someone doing this many requests on our on-premise data centers, I'd disable that account and send the owner a heart-warming letter asking them to fix their malfunctioning scripts (well they would be rate limited in the first place, but that letter still goes out).
If it's synchronous, 5 requests at once (waiting for response), that's probably going to be fine, but if you do all of that asynchronously then that's a problem for sure.
Imagine what would happen if there was another team doing the same thing, or if there were multiple - that would definitely be an issue, so your implementation, while it could work alone, is very inefficient and not scalable in grand scheme of things.
2000 / 30 => 66.6 requests per minute you need to do to finish before the next cycle. So say roughly 1.1 request/second; so yeah that can be throttled to avoid causing spikes, assuming, say, 5 requests per second, so each thread doing 1 req / 1 sec max you get to 5req/1s => 400 seconds => done in 6.6 minutes with plenty buffer in case of slow responses
Still, bad approach, it's kind of brute forcing something.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.