[MGNLUI-7086] Improve grid performance by using native JCR query offset/limit when publication status filter is not active Created: 04/Apr/22  Updated: 07/Mar/23  Resolved: 27/Jan/23

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: 6.3.0, 6.2.28

Type: Improvement Priority: Neutral
Reporter: Ilgun Ilgun Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: nucleus, performance
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Issue split
split to MGNLUI-7726 Make it easier to extend JcrDataProvider Closed
Relates
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLUI-7751 Rw Sub-task Completed Antonín Juran  
MGNLUI-7752 Implementation Sub-task Completed Roman Kovařík  
MGNLUI-7753 Preint QA Sub-task Closed Antonín Juran  
MGNLUI-7754 QA Sub-task Completed Jaromir Sarf  
MGNLUI-7763 Check failed addons test / partial re... Sub-task Completed Roman Kovařík  
Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Date of First Response:
Epic Link: [JCR] Search Performance issues
Sprint: Nucleus 28
Story Points: 3
Team: Nucleus
Work Started:

 Description   

Currently, we fetch all the nodes and then filter at the Java level. That has performance implications.

We should research how to achieve this on the JCR level directly and not rely on filtering via Java

 

 

At 08:00 minute

https://magnolia-cms.zoom.us/rec/share/Fkd9YuJdMIyisdTwKIDZh7MDGe3GcKMNWEsXT-1u1mLKsx8-EM65JoiBDhChZfFx.DVTpqAofUU7BsisO



 Comments   
Comment by Roman Kovařík [ 04/Apr/22 ]

how to achieve activation status filtering the JCR level directly and not rely on filtering via Java

It's unfortunately not possible due to complexity of the modified status calculation (takes published/unpublished versions into account) but could be indeed skipped in case the activation status filter is empty. 

 

Comment by Rico Jansen [ 05/Apr/22 ]

As our Team found the issue I looked at the way the status is calculated and came to the same conclusion.
The solution I thought of was to introduce an extra property in jcr containing the result of that calculation.
That would make it possible to do it on JCR level. However that would require quite a bit of extra code to maintain that property value.

Comment by Roman Kovařík [ 08/Apr/22 ]

Hi rico.jansen,

Thanks for the report and the suggestions. Really helpful feedback.

 

Discovery completed: 

As first steps we could go with

  • skipping the empty filter
  • make it easier to extend JcrDataProvider (it's already possible to provide a custom one via component mapping)

 

The solution I thought of was to introduce an extra property in jcr containing the result of that calculation.
That would make it possible to do it on JCR level. However that would require quite a bit of extra code to maintain that property value.

This could be a separate improvement ticket. There are other implications as maintaining the property could cause another problems in other environments such as:

  • increased amount of observation threads
  • observation thread would not only read but also modified the content which would results in
    • triggering other observations, again increasing amount of system threads
    • flushing the cache (environments with enabled cache on author)
  • mechanism needs to take not only current content but also the versioning workspace into account which increases the complexity even more
  • just for the record, this mechanism should be skipped on public instances

 

It would actually be much easier to provide a solution for specific projects where the implementors know / can test if the above could cause any issues in their environment than introducing a complex mechanism in the framework itself. Extendability of JcrDataProvider should help with that.

 

Best regards

Roman

Comment by Rico Jansen [ 08/Apr/22 ]

Skipping the filter is a good step and will improve overall performance. And in that case only if one needs to filter on activation status one would get the penalty.

Increasing extensibility is also welcome, it would make it easier to customize things if needed.

Introducing an extra property that needs to be maintained outside of the normal edit flow is indeed an improvement case. As I said that is the only way I see at the moment to get out of the java filtering solution.

And indeed its impact would be quite large as maintaining its value is not simple, observation would be the easiest solution but with all the issues you described.

The other one would be to hook into all the mechanisms that would possibly cause the activation status to change, but that is also not simple as there is quite a few places that do that and most likely not even possible as someone might have some process that would change the node directly bypassing all that. So observation it would be.

Generated at Mon Feb 12 09:43:00 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.