Expand my Community achievements bar.

SOLVED

DAM Sizing

Avatar

Level 6

Hi,

Is there any documentation for DAM sizing?

I found in the docs website more related to the Sites sizing. 

Do you have any some guideline for sizing Author and publish DAM instances?

I need some basical formula for sizing CPU, RAM and Disk.

Any inputs ar welcome.

Thanks

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Hi Francois,

sizing a DAM is a tricky thing, because there are so many variants of it based on the sheer number of variables. Some use it only for images (but have lots of them), others for video and video transocoding. One has millions of assets and uses the DAM just for storing, for others the DAM is the central hub which requested by many different asset "sinks".

Some advice when you sizing:

* for disk size: take the avg asset size, and calculate the impact of the renditions to it. Take into account that you might have versions. And make sure, that you can grow. That normally means no local disks, but rather a SAN. (I don't want to have 10 TB of local storage in a single box and run there my DAM ...)
* for CPU: CPU is cheap, if you take x86. 24 cores are affordable today.
* same for RAM. 64 GB aren't that expensive.

For the hardware calculation I'd rather spend 30k USD on hardware than 10 hours of meeting with various stakeholders and doing calculations for the same price. My experience is, that an exact sizing is very hard; and a prediction for the next 3 years is nearly impossible, as noone knows how the internet (or your DAM world) will look like in 3 years.

Disclaimer: That's my personal kind to do hardware sizing. Others might do it differently.

kind regards,
Jörg

View solution in original post

3 Replies

Avatar

Correct answer by
Employee Advisor

Hi Francois,

sizing a DAM is a tricky thing, because there are so many variants of it based on the sheer number of variables. Some use it only for images (but have lots of them), others for video and video transocoding. One has millions of assets and uses the DAM just for storing, for others the DAM is the central hub which requested by many different asset "sinks".

Some advice when you sizing:

* for disk size: take the avg asset size, and calculate the impact of the renditions to it. Take into account that you might have versions. And make sure, that you can grow. That normally means no local disks, but rather a SAN. (I don't want to have 10 TB of local storage in a single box and run there my DAM ...)
* for CPU: CPU is cheap, if you take x86. 24 cores are affordable today.
* same for RAM. 64 GB aren't that expensive.

For the hardware calculation I'd rather spend 30k USD on hardware than 10 hours of meeting with various stakeholders and doing calculations for the same price. My experience is, that an exact sizing is very hard; and a prediction for the next 3 years is nearly impossible, as noone knows how the internet (or your DAM world) will look like in 3 years.

Disclaimer: That's my personal kind to do hardware sizing. Others might do it differently.

kind regards,
Jörg

Avatar

Level 6

The publish instance will be only to have the assets activated to be available for external access.

So, it will basically serve the static assets.

I saw in a trainning video this baseline for publish sizing:

        - Case 1: 1.400.000 page views with simple appplication, simple template, full caching and 1000 activations per hour
            - 2 core machine should suffice,  16+GB RAM
        
        - Case 2: 1.400.000 page views with very complex appplication, very complex template, min caching and 1000 activations per hour
            - 8 core machine should suffice, 32+GB RAM

 

As I will not have page and template processing(unless for asset share), I think the first case would be the best match for my use case, but, I still think it has too much RAM considering that will be no(or little) page/template processing.

Does anyone have any inputs on this calculations?

Thanks

Avatar

Level 6

Hi Jorg,

Thanks for your reply.

Your considerations are very valuable.

Thanks