Storing assets
This article is meant to help you better understand storing assets in PaaS.
DX Cloud leverages the Digital Asset Management (DAM) module for managing assets such as images, videos, and documents. In some cases, you may have quite a lot of assets to manage.
By default, thumbnails are disabled to ensure optimal performance in DX Cloud.
Projects with a large volume of assets per folder can cause serious performance issues when thumbsnails are enabled.
If you wish to turn thumbnails back on, you can do so by setting thumbnails: true in the dam.subApps.yaml file.
We only recommend doing this if you have structured your assets in an optimal way to minimize any performance degradation.
How to handle many assets
The DAM can handle a very large number of assets and is used in installations with hundreds of thousands or even millions of files. To keep both JCR operations and the Assets app UI fast and usable, avoid very flat hierarchies and organize assets into folders, aiming for roughly 500 assets per folder and using subfolders where needed.
When your total volume of assets or the size of individual binaries starts to impact publication times, storage footprint, or operational workflows, consider offloading binaries to DAM 6.0, our External DAM integration framework, our DAM API, or one of our Incubator modules extensions.
For best performance with JCR assets, limit each folder to around 500 assets regardless of type (images, PDFs, etc.)
Use subfolders to stay organized and avoid performance issues.
-
Avoid placing too many assets in a single folder.
-
Use subfolders to improve performance and maintain structure.
How to handle large assets
We don’t recommend using publication for any assets above 2 GB. You should store anything of that size in an external DAM system and reference it from Magnolia.
Want to know more details about publishing assets?
When you publish an asset, it is fetched from the DB into the app server, converted from binary into a base64 encoded stream, and zipped for transfer.
Likewise, on the receiving end, it’s unzipped, decoded, and pushed from the app server to the DB.
Because of that, publishing huge assets is slow and resource-intensive for both author and public servers.