Performance issues while automatically propagating default fragments changes during deploy process

Issue

• Facing slowness issues when trying to add/edit a content page (other types of pages work fine). The slowness is observed when starting the portal and trying to add/edit the content page. After clicking on the edit button, the page keeps loading for around 30 minutes and a white screen appears for the time being.

Environment

• Liferay DXP 7.4

Resolution

• To resolve the slowness behavior, please navigate to the Application Menu → Control Panel → Instance Settings → Page Fragments (under Content and Data) → again Page Fragments → uncheck the 'Propagate Default Fragments Changes During Deploy Process Automatically' option and restart the server.

Additional Information

• There is a procedure during startup to update all the fragment entry links by fetching all the fragment entry links belonging to a given fragment entry into memory and then iterating over them and running the update logic on each one.
• However, the logic doesn't scale well for large portal instances with many detailed content pages, since it fetches every fragment link into memory at once.
• The option 'Propagate Default Fragments Changes During Deploy Process Automatically' allows an admin to enable/disable the propagation of changes for the Default Fragment on the startup. This option is active by default.
• When the option is disabled (unchecked), default fragments will not be propagated when the portal is restarted.
• Additionally, after disabling this option, a new 'Propagate Changes' button will appear that will allow to manually propagate the default fragments. This might help you to overcome the performance issues.
• This new button will trigger the propagation of all default Fragments in all sites (just like when you re-start). This process runs in async, users can move out of this setting screen and the process will not stop.
• The propagation of changes to the default fragment always happens in the deployment process by definition, it has always been established this way.
• There are some scenarios, where performance issues can be experienced (in specific cases), so for this, we have enabled the option to do the propagation after the deployment (i.e. manually using the 'Propagate Changes' button) to avoid performance issues.
• Related Article: OutOfMemoryError on startup when there are a lot of very large FragmentEntryLinks