[MGNLUI-5558] Adding many availability rules slows down app performance Created: 12/Dec/19 Updated: 11/Dec/23 |
|
| Status: | Open |
| Project: | Magnolia UI |
| Component/s: | None |
| Affects Version/s: | 6.1.3 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Richard Gange | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | dx-core-6.3 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Template: | |||||
| Acceptance criteria: |
Empty
|
||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||
| Epic Link: | Throughput improvements | ||||
| Description |
|
We have just discovered that availability rules in an app will bring down the app loading speed "to a halt" (see attached app file and screenshot gif animations). We're seeing app load times up to 20 seconds with 5000 nodes. The reason is that we have just placed rules such as these on the activate, deactivate and activateRecursive actions in the browser sub-app:
rules:
IsPublishableRule:
implementationClass: info.magnolia.ui.framework.availability.IsPublishableRule
IsNotDeletedRule:
implementationClass: info.magnolia.ui.framework.availability.IsNotDeletedRule
Disabling these rules bring the app-loading speed back to normal, and it is fast to work with again. Accessing the workspace that our custom app is using through JCR is fast regardless of the rules being applied or not (which makes perfect sense, as they are not applied to the JCR-browser app). This was the finding that led us to the realization that it was most likely the availability rules that's causing this. Internally these rules will process the nodes one by one. And it seems to us; even though only part of the tree is visible in the app (e.g. sub-trees are folded and thus not showing all nodes but only a very limited sub-set to start out with) all the nodes in the workspace are apparently being traversed by the rule-engine? Thus; Having only a few nodes visible or opening a subtree to show more and more nodes takes about the same amount of time. Loading and showing new nodes in the app causes the evaluation of the rules (at least; that is our guess at how magnolia is functioning internally)... The problem, to us, seems to be that for each node the number of rules that are in-place will be evaluated one at a time, and inside a rule you'll typically find this back-end java code: Node node = SessionUtil.getNodeByIdentifier(jcrItemId.getWorkspace(), jcrItemId.getUuid()); Which internally in the getNodeByIdentifier will call: session = MgnlContext.getJCRSession(workspace); if (session != null) { res = session.getNodeByIdentifier(id); } The problem being; That all of that takes time. The node is provided to the rule as an ID that needs to be assigned a session, that needs a workspace, that then needs to find the node using "getNodeByIdentifier". This will be repeated for each rule on each node, over and over. In our app with this speed-problem, we have introduced a total of 9 rules that are being evaluated for the various actions in the actionbar. This results in 9 calls to getNodeByIdentifier pr. node, 9 sessions, and 9 JCR round-trips fetching the same node. We think it would be a considerable performance improvement to e.g. pass the Node itself, instead of it's ID to the rule evaluation method. Short of that being possible, it would again likely be a big speed up to use e.g. a memory-cache getNodeByIdentifier for such repeated lookups. — Please advice - thanks in advance. |