[MGNLUI-3601] Thumbnail/List View are slow with large volumns of nodes Created: 21/Sep/15  Updated: 11/Mar/21  Resolved: 11/Mar/21

Status: Closed
Project: Magnolia UI
Component/s: workbench
Affects Version/s: 5.4.2
Fix Version/s: None

Type: Epic Priority: Critical
Reporter: Richard Gange Assignee: Unassigned
Resolution: Done Votes: 4
Labels: performance, pm, support, to-estimate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLIMG-213 Asset upload in ZIP file to DAM may c... Closed
relates to MGNLUI-4695 Implement a Vaadin8-based thumbnail view Closed
relates to MGNLUI-4968 Port thumbnails view to updated UI fr... Closed
relates to MGNLEESOLR-120 Use Solr for search indexing a large ... Closed
relates to MGNLUI-4348 Introduce drill down view beside tree... Closed
relates to MGNLUI-4349 Improve performance of filtering larg... Closed
relates to DOCU-616 Enhance asset documentation with sect... Closed
causality
relation
is related to MGNLDAM-623 Subapp thumbnail launches a massive a... Open
is related to MGNLUI-3373 Thumbnail View needs too much process... Closed
Template:
Epic Name: High asset load
Acceptance criteria:
Empty
Date of First Response:
Visible to:
Adrian Andermatt, Michael Rauch

 Description   

Our customer has an installation with between 10,000 and 100,000 assets.

The tree view is ok. but the author can't be used really because everything that leans on the list view does not work.
For the assets app this is the list view, the thumbnail view and the search.

What also happens that when you use one of those functions is they time out but stay in the Vaadin session.
So when you try to get in again it restarts the active view, which times out so you are effectively locked out.

You can use another browser or incognito-window to avoid this.



 Comments   
Comment by Richard Gange [ 01/Oct/15 ]

Additional Input

The description is good (although we have even more then 100000 assets).
The title only says slow, on our test instance it doesn't even return before the reverse proxy gives up.
So how slow exactly is unknown.

My own suspicion about this is that JCR isn't very fast translating the tree structure to a list and that is one of the
reasons this is so slow.

One of the things that get mentioned in MGNLUI-3373 is the LazyQueryContainer of Vaadin.
So that might be a good starting point as well.

It should be noted that they have an order of 300000 nodes. But at some point that actual number shouldn't really matter because "unresponsive" behavior can be reached lower numbers of nodes than 300000.

Comment by Thomas Comiotto [ 03/Dec/15 ]

The thumbnail and list views should only display the items of the current folder by default. This would not only be more intuitive for users cause that's what most file browsers do (e.g. osx finder), you would also avoid the problems with large result lists, e.g. users switch from tree to list view and the app freezes till the 300'000 item result list is generated that you probably didn't want to browse anyway.

So the thumbnail and list view should operate in the current folder context in account by default and switch to result list mode only if you enter a search.

Comment by Sebastian Tauch [ 26/Jan/17 ]

Our customer has the same problem. They have ~125000 assets in their dam workspace, and entering the list view leads to "infinite" loading and destroys the current session. This is especially frustrating when using the search functionality often, since clearing the current search term (manually or via the x-symbol) automatically switches to the list view.

Comment by Michael Büchele [ 12/Jan/18 ]

Any updates on this issue?

Comment by Antti Hietala [ 12/Jan/18 ]

mbperi Update: we are currently working on MGNLUI-4350 to see if Solr search can help with performance here. Solr would externalize indexing of content to a proper search platform. The native Jackrabbit JCR / Lucene search is not designed for indexing 100,000 binary assets - it was rather intended for JCR's own internal purposes. Jackrabbit search can comfortably handle a small number of nodes like what we have in the config workspace but it is inadequate for indexing massive numbers of nodes. With BL-343 we try to make easier for users to swap the JCR-based container to a Solr-based container via configuration.

(Improving search indexing will likely only solve half the problem. The display of assets may be a further reason for slowness.)

Comment by Thomas Comiotto [ 15/Jan/18 ]

What's BL-343?

Comment by Antti Hietala [ 15/Jan/18 ]

tcomiotto, BL-343 is now MGNLUI-4350.

Comment by Roman Kovařík [ 11/Mar/21 ]

All tickets in epic closed.

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