[PUBLISHING-246] extend definition configuration with Interactive publishing to avoid performance issues Created: 10/Jul/23  Updated: 18/Sep/23

Status: Open
Project: Publishing
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Roman Kovařík Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screenshot 2023-09-08 at 11.42.00.png    
Issue Links:
Relates
relates to MAGNOLIA-9053 Improve scalabity of publishing content Open
relates to PUBLISHING-247 DOC: Add a "Publishing performance" page Closed
causality
is causing PUBLISHING-260 Feasibility POC for interactive publi... Closed
dependency
depends upon PUBLISHING-260 Feasibility POC for interactive publi... 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:
Epic Link: Performance problems with too many child nodes
Team: Nucleus

 Description   

Steps to reproduce

a] Publish a recursively huge subtree with just a few modified items
b] Publish recursively folder with too many children 
c] Publish a large amount of nodes that were preselected at the same level

Expected results (ideas)

let the user know that publishing too many nodes can cause freezing the screen and performance issues / slowing down of app and provide the possibility to avoid too big publishing load

 

Proposals

a] in case of publishing big amount of nodes in recursive mode (publishing including sub-nodes) -  User is offered a dialog where he sees the publication options like in the screen below ( "Modified items (number) vs "Bulk (utilizing itemsPerRequest)") so he can pick the most reasonable one. The recommended one might be preselected.

 

For operation: Publish Inc. subpages adapt the dialog so the user can access all necessary information while selecting one of the options. This problem occurs only with big-size projects so make sure to make this functionality available not by default but by enabling it via definition.

 

 

Help tips:

  • Modified only - By selecting this option, you will publish only modified content
  • Publish all: 31 items - By selecting this option, you will re-publish all content regardless of status. This can cause the service to slow down temporarily (not recommended).
  • Publish all: in 3 larger batches - By selecting this option, you will re-publish all content regardless of status. All changes will be packed in batches to reduce the publishing load

 

 

 

Actual results

User is not warned in case of

  • publishing huge amount of items
  • publishing unmodified items

Workaround

Development notes



 Comments   
Comment by Dominik Maslanka [ 12/Jul/23 ]

Proposals:
1. show the dialog to the user with information about the number of nodes he is planning to publish (e.g. 10000 in case of a big project) and inform about the consequences and possible performance issues
2.  ask the user if he only wants to publish "modified only" ones
3.  bulk publication (publish chunks of nodes e.g. 100 nodes in 1 request)

Questions from the team:

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