Decreased scalability of XWiki caused by Notifications

The issue is that for each XWiki page the Notifications feature will traverse all the past events and apply grouping and filtering on them., and it's quite intensive.

This is done asynchronously so it's not affecting the response time for the user (even though the global page response is affected).

However it costs a lot in term of CPU and thus this means that an XWiki instance cannot support as many users as it used to, before the notifications feature was added. This is worse than before with the AS since the AS was only displayed on a specific page and if you were not on that page it was costing 0.

So we need to fix this. Ideally the notification information should only be computed when the users open the alert menu so that it doesn't cost anything for all page loads when the user doesn't need to view notifications.

However the issue is counting the number of alerts to display them above the bell icon.

So we need to either:

• Find a solution to not compute anything related to notifs till the user asks for it
• Or reduce the CPU required to compute them. One idea would be to have a memory cache and do the filtering and grouping for all past events and keep that info in memory. Then when a new page is loaded, only handle the events that happened after and update the memory cache. We need to check if this is possible or not and if it would take too much memory or not (since the caching would need to be per user).

In any case we have a global performance bug on scalability IMO that we need to handle/fix.