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 property was introduced with Magnolia 6.2.39.

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

Author instance before publishing

Public instance before publishing

Public instance after publishing - ordering fast

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

Author instance before publishing

Public instance before publishing

Public instance after publishing - ordering full

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

Author instance before publishing

Public instance before publishing

Public instance after publishing - ordering none

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

An 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: full

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.

Enabling and using showOptions with a data source that contains large data sets may lead to performance issues. See Link field for more details.

Feedback

DX Core

×

Location

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

You are currently perusing through the Performance tuning guide docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules