-
Bug
-
Resolution: Fixed
-
High
-
6.2.28
-
None
-
-
Empty show more show less
-
Yes
-
Yes
-
2
-
Yes
I am investigating performance issues on our migration to Magnolia 6.
When I first deployed it on our test server when I logged in de ui would be very slow and not show the results from the pages and dam app in the first screen.
Trying to open the pages app would take a very long time as well (probably related to the initial query on the website still running). Investigation showed that JcrSearchResultSupplier would query for all nodes in the websites repository using an empty wildcard like ('%%'). On our website repository with more then 100.000 pages this does not perform. It does this as well on the dam repository which has even more nodes than that. Those queries use a lot of memory as Jackrabbit traverses both indexes fully, which causes a lot of GC load.
As a workaround I created a modified JcrSearchResultSupplier to no longer generate those empty wildcard queries and this improved things quite a bit, the queries at least return in less then 10 seconds. However in our case this will not be sufficient as this is still too slow.
Measure and record the times before the change and after the change in this ticket using the big data environment.
- is caused by
-
ADMINCTR-226 Make Findbar search starting with an optional number of characters
- Closed
- is cloned by
-
ADMINCTR-389 Port to Master - Findbar iterates over all nodes in the pages/assets app on presenting the ui.
- Closed
- is related to
-
MGNLPER-190 Find and document opportunities to improve the response time of periscope
- Open