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:
-
Go to Admincentral.
-
Navigate to
config/server/version
. -
Click maxVersionIndex.
-
Click Edit property in the Action bar.
-
In the dialog, set Value to a maximum of
5
.
-
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. |