[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: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| 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 |
| 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 |