I have a question about the number of listener, or behavior.
Is there a recommendation on a maximum number of listeners that should not be exceeded so that the system runs without any problems?
I know that you should group many listeners together if possible. Also you can limit the action range by mapping. But if you would combine everything in one listener, the effort for the code review is consequently bigger.
The same question would be with the Behaviour.
There's no easy number or simple rule that would let you come up with one.
The only answer is "stop adding new ones when you believe they're starting to have an effect on performance".
Each listener and Behaviour has an overhead in that they need to do something when they're triggered, but a long listener that does a lookup and a batch update of linked issues, imposes more load than 10 listeners that just write a line to a log. All 11 of them have the same overhead. Grouping listeners together is a good idea as long as you can write efficient code for them, it reduces the overhead, but there's a balance to be had with simplicity.
So, while 1,000 listeners might well be "too many" in one Jira system, another might be fine with 10,000. It depends on what they're doing, not how many there are.
thank you for your detailed answer.
For now we are using only a few listener and behaviours but i had to ask if there is a critical number :-).
So, if I group listeners together and use mapping to distinguish them from others, I don't have to worry about critical mass?
We are just a little concerned that with many or a few large listeners the overview is lost. Therefore, i highly recommend my request for a better overview (SRJIRA-5461 ) ;-)
Thank you for your reply.
There's already most of your "better overview" in Scriptrunner - have a look at the built-in scripts and look for the "script registry"
There still is no single critical thing you can look at to judge the performance impacts. Each area works differently (listeners, post-functions, Behaviours, scripted fields, etc - all have different performance impacts).
The core of a performance calculation for scripts would be a function that takes account of the number of scripts being executed, what they do, and how they do it.
All you can really usefully do is write "good" scripts and test them against reasonably representative data. And for existing scripts, check none of them are erroring (errors often give you spikes in load as the system scrabbles to handle them)
That "erroring" is a nice hint. Thank you for that. I will observer our exisiting scripts for this kind spike.
The script registry gives the use a good overview, but in my opinion doesn`t work very well.
I think it would be a good additional view to see all listeners, behaviours, fields in one table and to filter very fast. So i can see all "items" related to the special tag / project.
In conclusion it would give the user a fast and short overview. :-D.
Now we had another topic.
But thanks for your reply.
Hello everyone, Hope everyone is safe! A few months ago we posted an article sharing all the new articles and documentation that we, the AMER Jira Service Management team created. As mentioned ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events