[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: |
|
||||||||||||||||||||||||||||||
| Sub-Tasks: |
|
||||||||||||||||||||||||||||||
| 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: | |||||||||||||||||||||||||||||||
| 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 |
| Comments |
| Comment by Roman Kovařík [ 04/Apr/22 ] |
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. |
| 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
This could be a separate improvement ticket. There are other implications as maintaining the property could cause another problems in other environments such as:
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. |