[PUBLISHING-254] Reduce the publishing load by optimizing ordering on the public instance Created: 13/Jul/23  Updated: 18/Sep/23  Resolved: 11/Sep/23

Status: Closed
Project: Publishing
Component/s: None
Affects Version/s: 1.3.10
Fix Version/s: 1.4.0, 1.3.12

Type: Improvement Priority: Normal
Reporter: Dominik Maslanka Assignee: Antonín Juran
Resolution: Done Votes: 0
Labels: VN-Testing
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: 7.5h Time Spent: 7.5h
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: File config.yaml     PNG File image(1).png     Zip Archive publishing-fast.zip    
Issue Links:
Relates
relates to MAGNOLIA-9053 Improve scalabity of publishing content Open
causality
relation
is related to PUBLISHING-285 Published node is not placed at corre... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
PUBLISHING-269 Implementation Sub-task Completed Antonín Juran  
PUBLISHING-270 Code review Sub-task Completed Adam Siska  
PUBLISHING-271 Pre-integration QA Sub-task Completed Adam Siska  
PUBLISHING-272 Final QA Sub-task Completed Quach Hao Thien  
PUBLISHING-275 Write unit tests Sub-task Completed Antonín Juran  
PUBLISHING-277 DOCu Sub-task Closed Antonín Juran  
PUBLISHING-286 Docu rv Sub-task Completed Adrian Brooks  
PUBLISHING-288 2nd rv/piQA - Deprecation of orderSib... Sub-task Completed Adam Siska  
Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Epic Link: Performance problems with too many child nodes
Sprint: Nucleus 43, Nucleus 44
Story Points: 5
Team: Nucleus
Work Started:
Approved:
Yes

 Description   

User Story: as a developer, I would like to optimize concurrent node publishing to reduce performance issues with publishing too many nodes simultaneously.

 

Context: Code provided to the customer is proposal for optimizing publishing of too many nodes at the same time on the same level.
customer is using PostgreSQL as storage and with limitations for too big flat structures in JCR trees he was trying to publish



 Comments   
Comment by Antonín Juran [ 25/Jul/23 ]

DISCOVERY

Suggested solution (bypassing imported nodes) could be easy implemented in publishing-receiver module see example here. Configuration of bypassOrderingVoters could be done similar way as in attached config.yaml on /modules/publishing-core/config path.

Comment by Adrian Brooks [ 29/Aug/23 ]

Moved from sprint 43 to sprint 44. 2 SP done, and 3 SP left to do.

Comment by Quach Hao Thien [ 11/Sep/23 ]

Solutions:

Allow users to config the ordering options: none, fast, full in PublicationCommand via Command's params

There is one case left: ordering by fast option would be tackled in PUBLISHING-285

 

Comment by Julie Legendre [ 11/Sep/23 ]

Hi all, would it make sense to improve the the title of this ticket to indicate what has been done (spotted when working on the 6.2.39 RN)?

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