How to increase per minute edits of Jira server issues via API?

[Cyber BBH]

Another way to put my question is: is there a hard limit to how many API calls I can make in a minute to Jira Server?

My use case involves daily updates of issues using external data sources- to update issues, I am using api/2/issue and I can never seem to get above ~500 messages/minute (~8 messages/second). I am using 48 parallel processes to bombard jira with API calls but there is definitely some bottleneck that is throttling my requests and I am trying to find those bottlenecks and adjust them to open up a bit more. I am running Jira on a RHEL 7 server with 24GB and 8 CPUs- using top, I can see the server is not the bottleneck as hardly any CPU resources are being consumed and free memory hovers at about ~3GB.

On the database, I have increased min and max DB connection pool settings to 40. Reviewing the database monitoring page, below is a typical graph for my instance:

As you can see, there is a spike when my parallel processes start but then it quickly goes down and hardly consumes any connections.

I would appreciate any guidance on what bottlenecks might exist and where to modify settings to alleviate those bottlenecks. Or any general guidance!

Thanks,

Akshar

[Nic Brough -Adaptavist-]

There is throttling hard-coded into the application, to prevent attacks such as yours taking it down.

[Cyber BBH]

Thanks-

Looks like the default throttling is a bit conservative when reviewing the DB monitoring graphs combined with CPU idle time on my Jira server hovering around ~75%.

Any way to modify any of those settings?

[Radek Dostál]

It's the number one enemy of Jira - trying to replicate a different system inside of it. 

Everytime you do a change on the issue, a lot of actions take place. The bigger the issue becomes, the longer those actions will take.

Better question is why are you trying to run 48 parallel updates against it?

Likely you would get better performance by building an actual connector (aka plugin) so you can skip out on unnecessary steps such as authorization, permissions, shared resources being locked by each request, change histories, notifications, etc. But that still doesn't change the fact it sounds that you are trying to turn it into a different system than it is.

Long story short what you're doing right now is more of a DoS attack under normal circumstances and you would probably get rate limited / temporarily locked out on any other Jira instance.