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.

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].

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.

tourCategories.yaml
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.

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].

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 ordering options are:

  • full (default): 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

    Author instance before publishing

    Public instance before publishing

    Public instance after publishing - ordering full

  • fast: The published node precedes the same node it did on the author instance when the publication was approved. Siblings before the published node aren’t ordered.

    Author instance before publication Public instance before publication Public instance after publication

    Author instance before publishing

    Public instance before publishing

    Public instance after publishing - ordering fast

  • 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

    Author instance before publishing

    Public instance before publishing

    Public instance after publishing - ordering none

The best option for performance is none; you can choose it if you don’t care about ordering nodes on the public instance. Fast, however, does preserve any existing ordering on the public instance while inserting the new node in the same position as it occurs on the author instance. Thus, the fast option offers a balance between performance and ordered content.

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: fast

Optimizing 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.

Feedback

DX Core

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the DX Core docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules