[MGNLPER-135] Long running searches cause performance issues in Admin Central Created: 18/Jun/20  Updated: 19/Mar/21  Resolved: 11/Dec/20

Status: Closed
Project: Periscope
Component/s: None
Affects Version/s: 1.2.1, 1.2.2
Fix Version/s: 1.2.3

Type: Bug Priority: Major
Reporter: Sönke Schmidt Assignee: Šimon Demočko
Resolution: Fixed Votes: 0
Labels: java11, maintenance, performance
Remaining Estimate: 0d
Time Spent: 2.75d
Original Estimate: Not Specified

Attachments: File 2020-11-09 10-15-33.mp4     Zip Archive logs.log.zip     HTML File pageCreationScript    
Issue Links:
Issue split
split to MGNLUI-6398 Remove grid scroll extension Closed
split to MGNLPER-141 Performance of JcrSearchResultSupplie... Closed
Problem/Incident
Relates
relates to MGNLPER-70 Physical memory usage is too high Closed
relates to MGNLPER-143 Out of memory still occurring as of 6... Closed
dependency
depends upon MGNLUI-6443 Use push instead of polling to update... Closed
relation
is related to MGNLPER-134 JcrSearchResultSupplier not consideri... Closed
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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Release notes required:
Yes
Date of First Response:
Sprint: Maintenance 14, Maintenance 36, Maintenance 37
Story Points: 8

 Description   

Running searches against a very big workspace using info.magnolia.periscope.search.jcr.JcrSearchResultSupplier might take a considerable amount of time. Especially during the initial search after logging in to Admin Central. E.g. as soon as you log in, a search is run against the website workspace without a query term.

As long as the search is running Vaadin UIDL requests are constantly sent to Magnolia.
Depending on network latency, these requests may take some time to complete. E.g. 100 - 200 ms.
This may results in Admin Central UI becoming very sluggish and sometimes impossible to navigate as long as the search is running.

Steps to reproduce:

  • Create a very big workspace (e.g. website) with ~ 50,000 nodes. (Alternatively prevent the completion of the search by setting a breakpoint in your IDE)
    • To quickly create that many nodes, you can use the attached script - execute it in Groovy module in Magnolia
  • Use a low latency network. (Alternatively throttle network speed in your browser).
  • Try to do your usual tasks in Admin Central. E.g. open several apps, create a page, etc.

A combination of the fixes provided in this ticket, alongside MGNLUI-6443 and MGNLUI-6398 should handle the performance issue.



 Comments   
Comment by Antonín Juran [ 09/Jul/20 ]

Couldn't reproduce. Tested with 50000 pages in website workspace. Could you please provide more details how to reproduce.

Comment by Richard Gange [ 26/Oct/20 ]

A had a customer facing this same issue. He reported that he was able to workaround the problem.

I disabled the default assets and pages.yaml with bootstrapping and setting enabled to false.

Then I created two new yaml configs with different names but with the same content from the original ones. This way I can still search with the dam and pages app, but with a different name.

 

Comment by Marvin Kerkhoff [ 09/Nov/20 ]

2020-11-09 10-15-33.mp4

I was able to reproduce this issue, you can have a look at the video.

Comment by Richard Gange [ 09/Nov/20 ]

For now the workaround is to use Java 8. It seems there is an issue with Java 11.

Comment by Šimon Demočko [ 09/Dec/20 ]

One of the factors hitting performance is infinite polling. There are two main reasons for that.

Combination of the open PR in this issue, MGNLUI-6443 and MGNLUI-6398 should handle the performance issues.

Generated at Mon Feb 12 10:29:04 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.