How big can a production CMS server get?

The short answer is as big as your blank check allows.

As you add users, workflow, translation, heavy publishing, and lots of opening/changing components, the CMS server size will inevitably increase.

Often times, multiple CM services are all enabled on one large machine for the enterprise, but the downsides of that are when one problem happens, all aspects of your CMS fail with it. Below I show what an infrastructure looks like that handles very large publishing loads and is scalable to add more load. The CMS also handles workflow services and translation integration with World Server.

You will have to click the image to open in a new window and zoom in to read the details.

Turning on only the publishing and transport services allows you to move the rendering of pages (the publishing load causing performance hits seen to the CMS user) over to another server or pool of servers. This also allows your dedicated publishing servers to scale as publishing load increases. This means that if publishing isn’t keeping up with demand, you can spin up another machine and add it to the pool to gain throughput. The less time editors stare at “Waiting for publish” the more work they complete!

The advantage of doing this doesn’t stop at scaling. Now your users do not see a slowdown in system performance when publishing. If publishing needs restarted, then the users can still work in the CMS and publishing resumes when the server comes back up. The publishers can be restarted in series to allow for zero downtimes.

In addition to the dedicated CMS publishers, you can also repurpose a dedicated DR (Disaster Recovery) CMS box to also pick up additional capacity when not in use. If you need the DR server it is as simple as starting the rest of the services and it is back fully purposed as a DR CMS environment in minutes.

As for the DR environment, it’s a fairly simple setup. Log shipping is setup between the Live CM database and the DR CM database. If DR environment is needed, you can simply turn off the log shipping and the DR CMS will start working.

There are some additional ways to scale out as needed. If you have a lot of workflow processes running you can have a dedicated machine just to run your workflow processes. This has similar pros to the publishers.

All static files go to central data center NAS servers which serve the individual web servers with the static content.

The size of the CMS machines are fairly large machines in the Tridion world. For production, we have 3 dedicated publishing servers with 48 CPUs and 256GB memory each. This allows for an optimal 108 rendering threads and 72 deployer threads for high-speed mass publishing.