How Big Can CMS Infrastructure Get?

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.

Tridion PROD Infrastructure 2013


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.





Improve the Publishing “Experience”

booksSo, you’ve got a release going on and some 20 people are publishing. A few of the editors only have a page or two to publish but some of them then select to publish the whole site and a few have published only whole Structure Groups!

How many of these publish by Structure Group! And, I ask, Why?

Why do it in the first place?

The first answer I hear a lot is

I don’t know exactly what to publish


Continue reading

Use GUI Extension to Solve for Content Re-Ordering

GUI Extension: Components Re-Ordering Dialog

  • SDL Best Practices recommend not localizing pages.
  • We originally used Container Components so that Editors can re-order components without needing page localization.
    • The use of Container Components introduced other issues as explained in this blog about Container Components.
    • The solution outlined below does not rely on containers.
  • SDL can store additional data on each component using Application Data. Application Data is applied to items across the blueprint and don’t require items localization.

Application Data to store components order

  • A GUI extension can update page application data to store components ordering.
  • Page Application Data is naturally local to each page
  • At publishing time, Application Data is also published within the page.
  • The Web Application can use the Page Application data to retrieve the components ordering and show them in the right order.

Known Issues

  • Where used does not show where the data has been localized and changed. Here are some possible solutions:
    • The GUI extension could flag these application data changes and display them back through the GUI
    • The GUI extension puts a component on the page with the ordering data and localize that component.
    • Where use functionality is extended to look for the page application data.

The diagram below shows how the components involved in the solution work together


Problems with Container Based Content Model

Containers are a common approach when designing CMS content models. They allow Authors and Content Editors to organize content hierarchically. While containers allow contributors to group, reorder, and organize content easily, they also add a lot of dependencies to the content across the system.

Containers add complex scenarios for simple tasks, including:

  • Publishing
  • Delete + Unpublish + Localize + Unlocalize
  • Workflow
  • Translation

Effects of using a container model:

  • “Where Used” filters are used extensively
  • Large amount of content dependencies lead to performance issues
  • Large amount of content manager transactions while publishing to ensure content integrity lead to stability issues
  • Multiple Database Transactions during Publishing
  • Complex content unpublish and deletion
  • Complex Experience Manager implementations (Experience Manager is not designed to use Containers)

Content Integrity Example:

In the scenario below, Tridion will attempt to maintain content integrity by publishing all pages using component instances. This example would cause a link propagation issue if the following conditions were met:

  1. Text Block – With image component is published within a page
  2. Application Include Container component is published within a page
  3. Buttons Actions tray component is published within a page
  4. Button App Include is published within a page


All I want for Christmas is an SDL Web 8 Developer Course (DXA)

Earlier in December, I had the opportunity to travel to Boston for the two-day SDL Web 8 System Administration Course in Wakefield, MA. It’s an excellent course, especially for those transitioning from Tridion 2013 to Web 8 and for people like myself who are traditionally weak in the area of sysadmin. I would highly recommend it.

Continue reading

SI4T-Solr 1.2 for Web 8

Looking at code you wrote three years ago can sometimes be a confronting experience. In case of the code I wrote for SI4T, this was no different. After you go through the six stages of debugging and cringe at the aestestics of the code base, the only thing you can do is rewrite the stuff with the knowledge of today and be solaced by the fact that your code is actually used in production environments and not breaking too much.

Continue reading

Web 8, SI4T and Storage Extensions

The release of SDL Web 8 has seen the biggest overhaul of the Content Delivery stack since Tridion 2011 and much of it has been applauded much, as the new Micro Services architecture and with it the ability to scale, deploy and be distributed in general, gives many more architectural options than just having an API in your web application connecting you to a database.

Building this while guaranteeing backward compatibility with the Tridion 2011/2013 CD stack is more than a major task and I for one am happy to see that that feat was pulled off really well. That is, unless you have overridden the default DAOFactory classes in your Deployer Storage Extensions, as is the case with the SI4T Storage Extensions. When testing SI4T with Web 8, it turned out that loading of the SI4T Storage Extension did not work in every scenario. This has to do with the subtler points of Spring Bean Class loading.

Continue reading

Creating a Simple SDL Web 8 DXA Environment

I set out to create a basic SDL Web 8 DXA machine with default everything installed and configured, following SDL’s installation documentation as closely as possible. I wanted to find the quickest, easiest and cheapest way to get up and running from scratch. Although it didn’t go as smoothly as I would have liked, the end result was indeed a fully functional SDL Web 8 development environment with the sample DXA site up and running, Topology Manager, a working Experience Manager, the ability to create new schemas and map them to application-side View Models, etc. In this post, I specify the key portions of SDL documentation used, some common issues encountered and some advice for getting set up quickly and easily.

Continue reading