Max number of listeners and / or behaviours?

[Fabian]

Hello,
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.

Kind regards

[Nic Brough -Adaptavist- · Accepted solution]

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.

[Fabian]

Dear @Nic Brough -Adaptavist- 

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.

Kind regards.

[Nic Brough -Adaptavist-]

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)

[Fabian]

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.

1. It needs a lot of time to load these scripts.
2. In the picture you can see the missing "script part". I need to click in the field and then the rest of the script appears.
3. I have to scroll down  to the needed part and the scrollbar can be veeeerrrryyy long.

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.

Kind regards.