List performance problems when combining many host groups with role filtering

Icinga Web 2
#1

We have strange low performance behaviour in IcingaWeb 2.7.1 or higher, when we use group name filtering in user roles. For instance, when we set the role attribute “monitoring/filter/objects” for a GUI login to, say,

host_groupname=XYZ*

to restrict visibility of hosts to those few groups, opening a services list page from a host view in the GUI takes 15-25 seconds!! :cold_face: (The behaviour is similar if just an asterisk is provided, or even a straight single group name!)

(URL looking something like this…) https://123.45.0.17/icingaweb2/dashboard#!/icingaweb2/monitoring/list/services?host=XYZ-SWITCH3

(We have more than 100 host groups defined in this instance.)

We have found a work-around by defining “visibility*” host variables, and then using those in the filter definition, but we wonder why this very long delay is happening? Is it a known bug in the IcingaWeb source? (And only with host group names?!)

P.S.: I did look to see whether this has been reported anywhere else before, but did not find anything. Please let me know if it’s been “solved” somehow, somewhere in the WWW. Thanks!

#2

Query performance with group filters was always an issue in larger setups. That’s just due to how the IDO is structured and how much JOINs are required. v2.7.0 especially had some issues with query performance, which got better and worse with v2.7.1 and was back to an acceptable level with v2.7.2. Though with the latest v2.8.2 we’re not aware of widespread issues with query performance.

Using custom variables in restrictions is way more efficient to apply on queries, hence the better performance you’re experiencing. If this is feasible for you in the long term, I’d recommend doing that.

You could also try the changes in the following PR, though be aware that this involves schema changes of the IDO. Don’t make use of that if you have working alternatives (e.g. custom variables) to choose from.

1 Like
#3

Thanks a lot! I don’t know my way very well around MySQL/MariaDB but under Oracle one could set up an index for joins that took too long. Following your advice we might now stick with the custom variables method. :v: