[MGNLUI-4335] Pulse rendering on login generate unnecessary waiting time Created: 08/Dec/17  Updated: 26/Jun/20  Resolved: 26/Jun/20

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

Type: Improvement Priority: Critical
Reporter: Frank Sommer Assignee: Unassigned
Resolution: Workaround exists Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File pulse.m4v    
Issue Links:
relation
is related to TASKMGMT-43 Expose a method to archive all tasks ... Open
is related to TASKMGMT-41 Pulse performance slows down as numbe... 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)
Date of First Response:
Visible to:
Gino Esposto, Jean-Marc Fazan, Michael Butti, Oliver Emke, Rainer Blumenthal, wolf bubenik
Story Points: 5

 Description   

The editors must wait more than 20 seconds after login. Magnolia initializes the pulse ui after login. With increased number of tasks the several queries against the tasks workspace are very slow. Following query executes in 17s.

SELECT * FROM [mgnl:task] WHERE (actorId = 'superuser' OR actorIds = 'superuser' OR groupIds = 'publishers' OR groupIds = 'editors') AND (status LIKE '%Created%' OR status LIKE '%InProgress%' OR status LIKE '%Resolved%' OR status LIKE '%Failed%') AND status NOT LIKE '%Archived%' order by [mgnl:lastModified] desc

I think the initialization of the whole Pulse UI should be more lazy, perhaps on click on the pulse icon.



 Comments   
Comment by Federico Grilli [ 09/Dec/17 ]

I suspect the bottleneck lies in the suboptimal way we get the total count of task items. The query for TasksStoreImpl#getTasksAmountByUserAndStatus is eventually executed at the general purpose method TasksStoreImpl#executeQuery(..). In there we do

...
final QueryResult qr = q.execute();
final List<Node> nodes = NodeUtil.asList(NodeUtil.asIterable(qr.getNodes()));
return Lists.transform(nodes, new Node2TaskConverter(new ObjectContentManagerImpl(session, mapper)));

which is fine when we need to retrieve a subset of tasks by specifying an offset and a limit in the query but totally overkill in order to just get the amount of items.

A better way, in this case, would probably be something like

...
final QueryResult qr = q.execute();
return qr.getRows().size();
Comment by Federico Grilli [ 12/Dec/17 ]

My hypothesis has been falsified by experimental trial. In the attached video pulse.m4v I set up a Magnolia 5.5.8-SNAPSHOT instance with 50K tasks and applied the proposed fix. I didn't see any noticeable improvements in terms of timing. As a matter of fact, most of the time is spent in executing the query and not in the following handling of the result set. Unfortunately, JCR SQL has no count() function or other means to speed up the query.
I can still apply the code changes, as they probably result in less memory consumption but, for the issue at hand, I'd rather follow the advice given in the related support ticket, and archive or remove the resolved tasks.

Comment by Federico Grilli [ 15/Dec/17 ]

Stopped progress and removed from sprint. Let's tackle this after 5.6.1 and 5.5.8 releases.

Comment by Richard Gange [ 26/Jun/20 ]

Tasks archiving script:

import info.magnolia.jcr.util.NodeUtil
import info.magnolia.task.Task
import java.text.SimpleDateFormat

archived= 0
taskManager = info.magnolia.objectfactory.Components.getComponent(info.magnolia.task.TasksManager.class);
session = ctx.getJCRSession("tasks")
qm = session.getWorkspace().getQueryManager()
query="select * from [mgnl:task] where status = '"+Task.Status.class.getName()+":Resolved'"
q = qm.createQuery(query, "JCR-SQL2")
results = q.execute()
tasks = NodeUtil.asList(NodeUtil.asIterable(results.getNodes()))
for (task in tasks) {
    ++archived
    String id = task.getId()
    taskManager.archiveTask(id);
}
println("archived "+archived+" tasks")
Comment by Richard Gange [ 26/Jun/20 ]

This issue can be helped by the fix mentioned in TASKMGMT-41. By aggregating the task data into single lucene documents you can reduce the overall number of docs and speed up the queries.

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