Best practices on DX Cloud

We have gathered a number of best practices for developing and running your Magnolia project on DX Cloud. We hope they will help you avoid common pitfalls and gotchas and get the most out of your project.

The General tips sections provides you with some straight-forward things to do for a successful project, whereas Best practice topics takes you to subpages that focus in-depth on a particular best practice topic.

General tips

Server versions

Limiting the number of versions under config/server is essential for maintaining optimal performance and managing resource usage. Excessive versions can bloat the repository, slowing down operations and increasing query times. They also consume significant disk space, making backups larger and slower to restore in disaster recovery scenarios.

Managing a large number of obsolete versions adds operational complexity with little practical benefit. Setting a reasonable version limit ensures the system remains efficient, while older versions can be archived externally if needed.

In this case, you should have a maximum of 5. To set this:

  1. Go to Admincentral.

  2. Navigate to config/server/version.

  3. Click maxVersionIndex.

  4. Click Edit property in the Action bar.

    1. In the dialog, set Value to a maximum of 5.

      config server maxVersionIndex

Cache

You can technically use the default Magnolia cache settings. However, this is unlikely to be sufficient for performance reasons unless you have a basic setup.

In order to optimize performance, create cache rules for images, REST, and other applicable items in the Cockpit. See Cache rules for how to create both browser and CDN cache rules.

Initialization times for larger applications

When migrating to DX Cloud or deploying applications with extensive storage requirements, indexing may take a significant amount of time. To prevent premature container restarts during these operations, it is essential to configure a startupProbe in the values.yml file with appropriate thresholds. This ensures Kubernetes allows sufficient time for your application to initialize fully before marking it as unhealthy.

The following configuration provides guidance on adapting startupProbe settings to accommodate lengthy startup times effectively. This applies to both magnoliaAuthor and magnoliaPublic.

After indexing is complete, revert the startupProbe to the default settings.

For more on this topic, see Helm values.

  startupProbe:
    enabled: True
    failureThreshold: 720 (1)
    periodSeconds: 10 (2)
1 Increase failureThreshold (number of attempts before failing) to accommodate indexing time for large storage or migrating customers in order to avoid indexing failures.
2 periodSeconds defines the interval (in seconds) between each probe check.

In this example, the probe is checked every 10 seconds 720 times, meaning 2 hours (7200 seconds) before the application officially fails.

Kubernetes naming conventions

For Kubernetes naming, including when adding a certificate in the Cockpit, you must adhere to the following naming standard.

"^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$"

  • Rules

  • Valid names

  • Invalid names

  • Must start and end with a lowercase letter or digit. (no trailing hyphens)

  • Can contain lowercase letters, digits, and hyphens (-).

  • Can have multiple segments separated by dots (.), each following the same rules.

  • Case sensitivity: only lowercase letters are allowed.

Here are examples of valid names, breaking down why they’re valid.

  • pod123

    • Starts with p (letter), followed by od123 (letters and digits), ends with 3 (digit).

  • a

    • Single character, a lowercase letter—minimal valid case.

  • my-pod-1

    • Starts with m (letter), contains hyphen -, ends with 1 (digit).

  • app.v1.prod

    • Multiple segments (app, v1, prod) separated by dots, all lowercase, no hyphens here but allowed.

  • x-y-z.a-b-c

    • Two segments (x-y-z and a-b-c), both follow the rules: start/end with letter/digit, hyphens in between.

Here are examples of invalid names, breaking down why they’re invalid.

  • Pod123

    • Starts with uppercase P (not allowed, only a-z).

  • my--pod

    • Contains double hyphen -- (allowed); this doesn’t violate the pattern directly; however, Kubernetes might have additional rules disallowing this.

  • my-pod-

    • Ends with a hyphen (not allowed, must end with a-z0-9).

  • .app

    • Starts with a dot (not allowed, must start with a-z0-9).

  • app..v1

    • Contains consecutive dots (not allowed, each segment must start with a-z0-9).

Optimizing AdminCentral

Tasks that have been successfully executed are marked as "resolved" and retained in the task workspace in your JCR repository. Resolved tasks can be marked as "archived" and will no longer be displaced in the Tasks app. "Archived" tasks can be marked as "removed".

Scheduling task cleanups help keep AdminCentral performing at an optimal level.

You can do this by writing a command or using the Tasks cleaner module.

The Tasks cleaner module is currently only tested against Magnolia 6.2.

REST

Delivery API response time and performance

Following these best practices help improve the response times and performance for the Delivery API.

  1. Minimize references.

    Using reference resolvers can impact the response times significantly. If the data contains a lot of referenced properties, the request processing times may be considerably longer.

  2. Minimize asset renditions.

    Each asset rendition config added to the endpoint definition increases the request processing overhead regardless of whether the asset renditions do or do not exist.

  3. Minimize response size.

    A large response can take longer to generate and return.

  4. Minimize the value of the depth property.

    Extra but unnecessary depths configured may have a major impact on response times. Even just one extra depth level can have an adverse effect on the responsiveness of the endpoint.

    For example, setting depth to 4 may take five seconds to process, whereas depth: 5 could easily increase it to twenty seconds.

    When needing to retrieve a hierarchical collection of nodes such as to build a sitemap, a navigation, or to represent the hierarchy of content in a content app, consider retrieving just one or two depths of content at once, and then making further requests as necessary.

  5. Adjust the caching configuration.

    Using cache can boost the performance of your endpoint. The default cache response threshold value is 500. This means that responses for data larger than 500 kilobytes are not cached.

    If your endpoint will be handling much larger chunks of data, consider modifying the cacheResponseThreshold property accordingly. For more details, see cache threshold.

Best practice topics

Feedback

PaaS

×

Location

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

You are currently perusing through the Magnolia PaaS docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules