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...

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 files on a shared File System. The Deployer workers monitor the file system and upon noticing a change, they start deploying/undeploying the package. In order to setup this File System notification system, we must first create a shared File System (shared across the Deployer Receiver and all Deployer Workers). In order to do that, have a look at an earlier post Using Elastic File System for Out-Scaled Deployers . Once the EFS is in place, for example under folder /efs01 , we can configure the Deployers to use this share file system in the file deployer-config.xml , as per below: <Queues> <Queue Default= "true" Verbs= "Content" Adapter= "FileSystem" Id= "ContentQueue" > <Property Name= "Destination" Value= "/efs01/deployer-queu...

In a scaled-out scenario for Content Delivery Deployers, it is possible to setup an AWS ElastiCache Redis DB as the Binary Storage medium for incoming transport packages. The Deployer Receiver writes these transport package zip files into the Binary Storage Redis instance. Then it is up to the Deployer Workers to read these zip files as they deployer/underploy the content. Below, we present the configurations for an AWS ElastiCache Redis acting as storage medium for transport packages. Start by simply creating an ElastiCache Redis instance in AWS console. This whole step might take you 5 minutes :) AWS will give you the hostname where the Redis DB is available and the port, usually 6379. In your deployer-conf.xml , setup this Redis instance using the BinaryStorage node format as below:     <BinaryStorage Id="RedisStorage" Adapter="RedisBlobStorage">         <Property Name="Host" Value="10.10.2.232"/>       ...

In a scaled-out scenario for Content Delivery Deployers, it is possible to setup a shared file system as the Binary Storage medium for incoming transport packages. The Deployer Receiver writes these transport package zip files into the Binary Storage folder. Then it is up to the Deployer Workers to read these zip files as they deployer/underploy the content. Below, we present the configurations for an AWS Elastic File System (EFS) acting as storage medium for transport packages. Start by simply creating an EFS in AWS console. This whole step might take you 5 minutes :) AWS is going to generate a hostname where this file system is available and it will give instructions on how to mount it in your server. For example, in Linux CentOS, one can mount an FS using the mount command. The following command will mount the EFS drive under folder /efs01 on the current server: sudo mount -v -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-...

This post is part of a bigger topic Autoscaling Publishers in AWS . In a previous post, I mentioned the LifeCycle Termination Hooks for our Auto Scaling Policy . In this post, we see more details about this hook and how it is actually used to gracefully shutdown service on the instance that is about to be terminated. As per earlier post, we defined one termination hook in the Auto Scaling Policy, named 'sdl_terminate_publisher': Next, we use this a CloudWatch event to execute a Lambda Function that performs the graceful shutdown of the Publisher service on the instance, and then releases the termination hook, so the instance can be terminated properly. In CloudWatch, create a new Rule as per below: Event Source: Event Pattern Based on service: Auto Scaling Event Type: Instance Launch and Terminate Specific event: EC2 Instance-terminate Lifecycle Action Specific group: sdl_publisher-asg Target a Lambda function to be executed when this event triggers: SDL...

This post is part of a bigger topic Autoscaling Publishers in AWS . In a previous post we talked about the Auto Scaling Groups , but we didn't go into details on the Scaling Policies. This is the purpose of this blog post. As defined earlier, the Scaling Policies define the rules according to which the group size is increased or decreased. These rules are based on instance metrics (e.g. CPU), CloudWatch custom metrics, or even CloudWatch alarms and their states and values. We defined a Scaling Policy with Steps, called 'increase_group_size', which is triggered first by the CloudWatch Alarm 'Publish_Alarm' defined earlier. Also depending on the size of the monitored CloudWatch custom metric 'Waiting for Publish', the Scaling Policy with Steps can add a difference number of instances to the group. The scaling policy sets the number of instances in group to 1 if there are between 1000 and 2000 items Waiting for Publish in the queue. It also sets the ...