You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I am getting ratelimit on hitting the endpoint `/rest/api/2/search`. In `x-ratelimit-limit ` header it's showing 600000. Not sure what this conveys. As we are not hitting 600000 requests.
In our use-case we are hitting the `rest/api/2/search` endpoint with 2000 requests with a concurrency of 5. This process happens every 30mins
Need to know how many request can we make per minute or per hour or in concurrent?
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.