a generic question...
with power of Atlassian's own Automation add-on and a new https://marketplace.atlassian.com/plugins/com.codebarrel.addons.automation/server/overview comes a price paid in resource utilization... what does it mean for a busy JIRA instance?
For example: for an "issue created" trigger - every event (across all projects) is being checked against a condition (some JQL). Sounds like a lot of activity if we have hundreds of new tickets created every hour and only 1 might trigger an event per day... is the overhead of automation triggers worth it? or adding multiple (dozens to hundreds) custom events is the way to go in this case?
I guess I am after a recommendation about a sweet spot between multiple custom events in the system vs one generic event (issue created) checked against multiple JQL conditions. Or similar...
what would be a more effective solve resource-wise? and are these automation plugins resource-hungry?
I'm the co-founder of Code Barrel - we are the creators of https://marketplace.atlassian.com/plugins/com.codebarrel.addons.automation/server/overview.
Myself and my co-founder worked for Atlassian on JIRA for over 10 years, so we understand JIRA and performance concerns for large customers pretty well. Having said that there's no simple answer when it comes to performance - your mileage may vary depending on your unique setup (server hardware, database, memory, number of issues, datacenter, number of active users...).
However I can shed a bit of light on some of the architectural decisions around how we implemented Automation for JIRA Server to reduce its performance impact:
We may revisit the single threaded rule processor in future when we get more large server customers trying our add-on, but we know from Cloud that this approach scales quite well. In Cloud we have a single Kinesis queue processing requests from *all* JIRA instances using our add-on (several hundred). So this is pretty much equivalent to the single threaded model in server, but with multiple JIRA instances. Granted Cloud instances are much smaller and less active than large JIRA server instances, but it's still good validation. In cloud we can simply scale horizontally by adding more shards to the Kinesis queue. In server we could use a similar approach by adding more rule executor threads but for now we believe it's better to keep the footprint small.
So in summary I wouldn't be too worried about pre-maturely optimising events or rules in your system. The impact should be quite low.
Hope this helps - if you have any more questions we'd be happy to answer them here!
We use quite a lot of triggers for a lot of different events in our workflow and things seem to be running fine. We don't create hundreds of tickets an hour but we do have a fair few triggers (push notifications to slack and internal systems etc) and our system is working fine.
Thanks for signing up for Jira Ops! I’m Matt Ryall, leader for the Jira Ops product team at Atlassian. Since this is a brand new product, we’ll be delivering improvements quickly and sharing updates...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs