Yet Another Tridion Blog

In order to squeeze the most performance out of the publishing in a Tridion, SDL Web system, there is a high amount of parameters and configurations that must all be optimized. This post presents a few of these parameters, especially in the context of AWS infrastructure. CME The Tridion GUI, the Content Manager Explorer server is a normal Tridion installation, but with Publisher and Transport services disabled. This server is only used for running the website -- the CME. Publishers Publisher servers are Tridion installations without the CME. Namely these servers have the Publisher and Transport services enabled and any other Tridion services, if installed, are disabled. The purpose of a Publisher is simply to lookup publishable items in the Publishing Queue and proceed to render them, hand them over to the Transport service and have the transport package pushed to the Content Delivery. Publishers should use approximately twice the number of CPU cores as number of renderi

When a Deployer Receiver receives a transport package, it notifies the Deployer Workers there is 'work' for them to do. This notification can take the form of JMS messages sent using some kinds of queuing mechanism. This post describes the Amazon Simple Queuing Service (SQS) to send these notifications. The Deployer workers receive these messages from SQS and they start deploying/undeploying the package. In order to setup this notification system, we must first create the SQS queues and configure them across the Deployer Receiver and all Deployer Workers. Start by creating Standard Queues using all default properties. We need 3 queues (commit, content, and prepare): Once the SQS queues are in place, we can configure the Deployers to use them in the file  deployer-config.xml . Amazon gives us the queues URLs. We need to specify the URL base separately, and then simply name the queues individually, as per below: <Queues> <Queue Default= "true"