While working on MAGNOLIA-9181 I found that a vanilla CE instance registers 3463 observation listeners, 3421 of which are module configuration change listeners. When we profiled publication, we saw a lot of internal observation processing happening in Jackrabbit, maybe this was the cause. If so, we should think of a leaner mechanism for modules to listen to configuration changes.

Discovery

• This was already discussed at the DX Core Performance: weekly sync 3: the recording has some good ideas from mgeljic at the beginning:
  • deprecate/remove JCR configurations
  • make observation lass fine granular (with this one we have to take care not to move the bottleneck from processing the events within Jackrabbit to within Magnolia).
• OTOH, all the listeners are registered on the config workspace, while publishing pages happens on website. From looking at the code Jackrabbit is clever enough to not spend much time processing observation pertaining to different workspaces. We might want to confirm this through some profiling though.
  • When publishing a page there's only a few listeners invoked: logs like 2024-01-19 15:15:13,667 DEBUG .jackrabbit.core.observation.ObservationDispatcher: event delivery to 3 consumers started... appear a few times.
  • Configuration changes however cause many listeners to be invoked: 2024-01-19 15:18:40,478 DEBUG .jackrabbit.core.observation.ObservationDispatcher: event delivery to 2012 consumers started...
• I couldn't see a significant negative impact on performance from these listeners. The only thing that shows up are many calls to org.apache.jackrabbit.commons.observation.ListenerTracker#recordOneSecond. To mitigate this and avoid cluttering the monitoring I suggest to exclude the EventListenerMBean registrations for the config workspace.