Automation for Jira Can Take a Long Time to Link Issues
Asked by Jeff Gordon:

I have implemented a rule such that when an issue of a certain type is created in a single project I run a JQL to find other issues in the project created by the same reporter within the last twelve weeks. Everything works correctly but it takes a really long time to run. I.e., one run took 30 minutes to link 35 issues. It even takes 15-30 seconds to link 4-5 issues. The net result is the rule quickly becomes throttled due to exceeding its 12 hour allotment (I know I can increase this but...).

I know the JQL takes less than a second so I don't think that's the problem. It's definitely related to how many issues will be linked.

Anyone have any similar experience or ideas on this?


Answers:
author: Mark Segall
body: Hi [@Jeff Gordon](/t5/user/viewprofilepage/user-id/4665734) and welcome to the community!

Can you share a screenshot of your rule? That would help identify whether there are any opportunities for optimization.

comments: author: Jeff Gordon
body: Here's the rule.

![screenshot-1.png](https://community.atlassian.com/t5/image/serverpage/image-id/188235iFB417F96B8F6C6DD/image-size/large?v=v2&px=999 "screenshot-1.png")


author: Mark Segall
body: Thank you [@Jeff Gordon](/t5/user/viewprofilepage/user-id/4665734)

Your rule seems pretty straightforward to me. However, is it correct to assume that you're using Jira Server? If so, there could be any number of environmental factors that could be playing into your execution times (CPU, RAM, etc.). I would check with your Ops team to make sure that they're not shorting Jira on resources.


author: Jeff Gordon
body: Jira Data Center.

I've switched to using a scriptrunner script as it's able to link the same number of issues in about 15% of the time.


author: Bill Sheboy
body: Hi [@Jeff Gordon](/t5/user/viewprofilepage/user-id/4665734)

Very curious symptom...

Why do you believe the JQL is executing in less than a second for that branch?

How many issues is this rule trying to link, and is the number what you expected?

Kind regards,  
Bill


author: Jeff Gordon
body: I can execute the JQL in issue navigator with a given reporter and it's always very quick returning results.

It can link anywhere from 1 to 41 (most I saw). The time seems to grow exponentially with number of issues being linked.


author: Bill Sheboy
body: Thanks, Jeff.

The comparison of the JQL performance with defined values for key and reporter versus the dynamic lookups may not be equivalent.

Would you please post the complete JQL used in that branch and an image of the branch component details in the rule?

Also, would you please post an image of the audit log details showing an execution that took 30 minutes to link 35 issues? That may show something to indicate what is happening. Thanks, again!


author: Jeff Gordon
body: **JQL**:

project = TechLounge and key != {{issue.key}} and issuetype in ("Service Request", "Problem") and reporter = {{issue.reporter}} and ( created \>= -12w or status not in (Closed,Complete,Completed,Resolved,Done))

**Branch Rule**:

![image-2022-03-17-13-49-29-797.png](https://community.atlassian.com/t5/image/serverpage/image-id/188718iA1F6ACD0428CA3D7/image-size/large?v=v2&px=999 "image-2022-03-17-13-49-29-797.png")

**Audit Log**:

![image-2022-03-17-13-53-55-550.png](https://community.atlassian.com/t5/image/serverpage/image-id/188719iCDB81469BF08DBAA/image-size/large?v=v2&px=999 "image-2022-03-17-13-53-55-550.png")


author: Bill Sheboy
body: Thanks, Jeff. I have observed JQL runs slower with negative conditions, so I wonder if you invert the status test to be positive what will happen to performance. For example:

... status IN (*all possible other status values*) )

or if I am interpreting your query correctly

...statusCategory = "In Progress" )

Also, what is the significance of the test for created \>= -12w? Is that to link all frequent reports from a specific reporter? If that is not needed, you could remove the entire OR clause, and that probably will speed things up a bit.

JQL is not a SQL, so we are guessing without testing what happens to performance. :\^)