You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.