[MGNLUI-3373] Thumbnail View needs too much processor time Created: 06/Mar/15  Updated: 03/Nov/16  Resolved: 27/Apr/15

Status: Closed
Project: Magnolia UI
Component/s: workbench
Affects Version/s: 5.3.7
Fix Version/s: 5.3.10, 5.4

Type: Bug Priority: Critical
Reporter: Christian Schroeder Assignee: Aleksandr Pchelintcev
Resolution: Fixed Votes: 1
Labels: performance, support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
causality
is causing MGNLUI-3554 Thumbnail View in magnolia 5.4 doesn'... Closed
relation
is related to MGNLIMG-162 Ignore ClientAbortExceptions (broken ... Closed
is related to MGNLUI-3601 Thumbnail/List View are slow with lar... Closed
is related to MGNLIMG-158 Add caching support in node-based par... 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
Date of First Response:
Visible to:
Adrian Andermatt, Michael Rauch

 Description   

Our customer has an installation with between 10,000 and 100,000 assets. Opening the thumbnail view causes the server to consume high amounts of processor time. Magnolia is not responsive while creating those thumbnails.

I recreated the problem on our dev system with much less assets (about 1,000) and it seems to hang for more then five minutes now. (java process at 380 %)



 Comments   
Comment by Christoph Meier [ 23/Mar/15 ]

Instead of getting a solution "only" for the thumbnail container, it could be worth to come up with a more general solution for "Flat container with caching and lazy loading mechanism for 'JCR-free content'".
The thumbnail container also requires these 2 things (caching and lazy loading mechanism) and a more generic solution would be a very nice "starting point" for every flat container for custom content apps.
(For sure the same is true for tree-based containers ... )

May be Vaadins LazyQueryContainer could be a starting point.

Comment by Tom Wespi [ 27/Apr/15 ]

thanks Aleksandr!

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