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.
Log entries when publishing all 15 nodes separately
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].Copy
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.
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.
Log entries when publishing with itemsPerRequest equal to 10
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].Copy
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.
Previous versions used the orderSiblings property to configure ordering on public instances.
If you have configured orderSiblings: false (/modules/publishing-core/config) on the public or both instances, items might become unordered on public instances.
The ordering options that you can use for publishing actions are described below.
fast Default
full
none
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.
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.