I’m working on a performance tweak around searches.
I’m in a connect app and using AP.Request and I’m trying to figure out:
a) What’s the optimal pagination size to request. I know I can get 50 issues at a time by default and I can go up to 100 - should I though?
b) How many concurrent requests can I have before Atlassian SREs comes and has a chat with me?
For the purpose of this discussion - assume that I’ve got somewhere in the range of 5000-10000 issues to fetch.
The reason I’m asking the question is that my experimentation is showing that increasing the number of issues isn’t necessarily giving me a direct gain - I’m guessing due to json serialization/deserialization and paging. However increasing the concurrent requests seems to give a much more impressive gain for me…
5 Likes
I would recommend asking for as many issues as you can (ie start at asking for 500 or 1000) and then use whatever maxResults value is in the first response for all subsequent requests.
The reason is that if you make concurrent requests you run the risk of consuming all of Jira’s database connections. Last I heard from Atlassian, all end-users (humans using a browser) and apps are all competing for database connections, so the more request you make concurrently (particularly search requests), the harder it is for everyone and everything else to make requests.
We have performance tweaked our apps by counter-intuitively making them run requests one-by-one, rather than concurrently.
Edit: I’ve only seen SREs jump in and rate limit instances that have well-paying customers. I tried performance testing on a developer Cloud instance and had no problems at all making ~200 req/sec to one REST API endpoint…
3 Likes
How many concurrent requests can I have before Atlassian SREs comes (…)
Why would they come? AFAIK there is rate limiting in Jira Cloud already: Are there rate limits for JIRA Cloud APIs? - #23 by czawadka
So I guess (and have experienced such behavior in own apps) that increasing number of requests has an upper limit. Even worse: the limit is fluctuating - you can’t assume it is 200 or 500 r/s, because the pool is depleted also by requests coming from other apps and Jira as well. And that’s something you don’t have a control over…
Or do you anticipate that ‘search’ requests generate significantly bigger load on Jira backend than the normal usage? 
2 Likes
Hi,
From my experience, I would say the best option is to make one request to get the first response. If there are more issues to fetch, you could generate all the necessary requests and push them to a queue with a limited number of consumers.
I think it isn’t a good idea to fetch that amount of data in the frontend concurrently, it will be tricky to predict the customer bandwidth.
On the backend we are asking 100 issues per request in a queue with 20 consumers. For 10,000 issues you will need 100 requests. Assuming each request will take a maximum of ~4 seconds, you can get 10000 issues in about 20 seconds.
Until now I had no problems making ~25 requests at a time for this use case. However, I didn’t find a perfect solution to avoid the Too Many Requests error or get the remaining requests until an error.
Regards,
Paulo Alves.
Hey @danielwester any updates on the best page size to use for bulky queries from your experience over the years? Thanks!