Publishing performance
On this page, you’ll find an outline of some possibilities to increase publishing performance. Specifically, you’ll read about options to improve the handling of publishing many nodes simultaneously, reduce the number of requests sent to the server, and optimize certain database parameters.
Publishing too many nodes at the same time can cause massive numbers of publication requests. This is illustrated in the example in the next section.
Publication requests
Consider the tour categories depicted below in the Tour Categories app.
If you publish the root node, it’ll generate 15 requests as it is with the out-of-the-box configuration.
23-08-08 09:55:59,065 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root].
2023-08-08 09:55:59,234 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/tour-types].
2023-08-08 09:55:59,253 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/tour-types/offPath].
2023-08-08 09:55:59,270 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/tour-types/family].
2023-08-08 09:55:59,287 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/tour-types/ecotourism].
2023-08-08 09:55:59,303 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/tour-types/cultural].
2023-08-08 09:55:59,320 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/tour-types/beach].
2023-08-08 09:55:59,336 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/tour-types/active].
2023-08-08 09:55:59,351 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/destinations].
2023-08-08 09:55:59,365 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/destinations/polar].
2023-08-08 09:55:59,382 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/destinations/asia].
2023-08-08 09:55:59,399 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/destinations/africa].
2023-08-08 09:55:59,414 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/destinations/europe].
2023-08-08 09:55:59,429 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/destinations/southAmerica].
2023-08-08 09:55:59,443 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/destinations/northAmerica].In this example, 15 requests is not a massive amount of requests, but if you had many more nodes, you can see how quickly the total amount of requests could accumulate when publishing an entire folder.
Fewer publication requests by publishing pages separately
If you publish a node in your browser app, you can also publish all subnodes and subpages. This publish-by-folder approach might be convenient if you publish several unpublished pages in the same folder. However, a folder containing many published pages would create unnecessary publishing requests. In this case, you should publish the folder using the itemsPerRequest option described below.
Fewer publication requests using itemsPerRequest
You can reduce the number of publishing requests created by configuring the itemsPerRequest property for the browser view in the tourCategories.yaml file. For example, let’s look at what happens when we allow up to 10 items per request.
subApps:
browser:
workbench:
contentViews:
- name: tree
columns:
jcrName:
editable: false
actions:
editCategory:
appName: tourCategories
addCategory:
appName: tourCategories
publish:
params:
itemsPerRequest: 10 (1)| 1 | itemsPerRequest is set to 10 |
After clicking the Publish action, you’d see that there are now only 3 publishing requests in the log. This is because the folders under root each contain less than 10 items, so the items within each folder can be published together rather than in separate requests.
2023-08-08 09:57:37,366 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root].
2023-08-08 09:57:37,398 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/tour-types].
2023-08-08 09:57:37,455 INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/root/destinations].Please go to the Configuring itemsPerRequest section for more information on the configuration details for itemsPerRequest.
Additional settings
Optimizing ordering on the public instance
Concurrently publishing nodes may have a negative impact on performance depending on your setup, for example, if you use a Postgres database and have a large, flat data structure in JCR.
To mitigate this, use the ordering property to avoid large numbers of nodes being published simultaneously.
The ordering property defines the order in which nodes and their siblings are published on a public instance.
|
The Previous versions used the |
The ordering options that you can use for publishing actions are described below.
Best for balance between performance and ordering content.
fast: The published node precedes the nearest next sibling existing on all author and public instances when the publication was approved. The order of siblings of published nodes on public instances is not otherwise affected.
| Author instance before publication | Public instance before publication | Public instance after publication |
|---|---|---|
|
|
|
Best for properly ordering content.
full: The published node and all its siblings appear in the same order as on the author instance when the publication was approved.
| Author instance before publication | Public instance before publication | Public instance after publication |
|---|---|---|
|
|
|
Best for performance. Does not order nodes on the public instance.
none: The published node appears after any sibling nodes on the public instance.
| Author instance before publication | Public instance before publication | Public instance after publication |
|---|---|---|
|
|
|
An example configuration for a publish action is given below, including the ordering property, which needs to be inside the params section.
publish:
icon: icon-publish
$type: jcrCommandAction
command: publish
catalog: versioned
params:
ordering: fastAn example of the full ordering configuration for a commit action in the workflow-pages module is given below.
commit:
class: info.magnolia.module.workflow.action.WorkflowCommandActionDefinition
params:
ordering: fullOptimizing dead nodes in PostgreSQL
If you are using a PostgreSQL database, you can adjust some vacuuming options to improve publishing performance. For more on this topic, please look at the section on publishing massive numbers of publication requests.
Optimizing link fields
Enabling and using showOptions with a data source that contains large data sets may lead to performance issues. See Link field for more details.