Recently, Chris Morgan of Building Blocks (a UK SDL partner), penned an article about scaling out the deployer. It is a good article and it is good to see more scaled publishing scenarios being implemented with customers.
In SDL Tridion 2009 particularly and 2011 less so, the deployer can be a bottleneck when you are trying to publish large volumes of content to your websites. Since the outset of SDL Tridion, customers have been growing in volume demand for updates to their websites. Moreover, the timeliness of the updates is become more and more important. The major difference between 2009 and 2011 is that 2011 is multi-threading, meaning that a single deployer can deploy more than one item at a time. Does not sound like much, but the multi-threaded change allows an ever larger amount of content to be published. However, it does need to be setup well and more over tested. If you want the best out of your publishing you must test the setup well.
Typically, when you ran up against the deployer bottleneck in 2009 you implemented multiple deployers. This you can still do in 2011 to get yet more throughput (because you add multi-threaded, multi-deployers). However, there are various things you need to take into account in order to ensure that you don’t run into problems.
If you read Chris’ article you get the idea of how you do this. However, I must make some corrections. The overall setup is fine but as Chris notes you can run into race conditions of multiple deployers trying to update the same content at the same time. For this reason, the setup described is not supported; you will get failures. However, there is hope! To avoid the race conditions you need to modify the setup as described in the blog post.
What is described in the post is that you have multiple deployers that are deploying all content from all publications. Instead you must have multiple deployers that are in their own right dedicated to publishing content of given publications. For instance, if you have 10 deployers you must split the publications you are publishing over each of the ten and not have any duplication. For example:
- deployer 1
- publication a
- publication b
- deployer 2
- publication c
- publication d
- etc…
This configuration you do in your publishing targets on the Content Manager and for simplicity sake each of your deployers can be configured 100% the same.