Content Management System with a separate Publisher Server

Question

To achieve a better performance of the publications tasks, I have been thinking to scale out the content manager system with a dedicated publisher server. First of all, I have been asking Tridion Support and scale out publisher service seems easy (I am not sure if I have all the needed information).

But now I have the doubt of how the communication occurs between the Tridion CM server and the publisher server in this scenario (In the other side the recommendation is that publisher server and deployer server communicate through HTTP(s)). It is enough that the publisher server has a valid connection to the CM database? How the Tridion CM server knows how to communicate with Publisher server and which protocol to use?

Thanks in advance!

Answer 1

The Publisher machine is basically a CM machine that users don't have access to. All communication to the publisher service (even if it is running on the same machine) is done via some database tables (exposed in the UI as the Publishing Queue, but obviously this is a simplified view of it).

Basically the publisher service, on startup, starts "listening" to the publish queue, and will start picking up jobs from there whenever they appear. It has all the features you would expect on a system like Tridion - the publisher service will lock the job so that other publishers don't work on it, etc - and then handle the resolving, rendering and transporting of the publishing package.

It really is that simple. You can go into a lot more complex configurations, with certain publishers listening only for jobs from a given publication, for a given target or for a given priority, but if all you want to do is to make sure it's a separate box that handles the publishing load then you just have to:

• Get a license for the publisher machine
• Install it as a normal CM box, connecting to the same database
• Deploy any event systems you may have that are triggered by publishing actions
• Deploy any custom resolvers or custom renderers you may have developed
• Stop IIS
• Stop the Publisher service on the original CM box

You're good to go.

EDIT

Following up from comments, the Publisher and the Transport service work in tandem. Each publisher service talks to "its own instance" of the Transport service via JNI (there's a lot of reasons why the Transport is built in Java, which made sense back in the day and perhaps not so much today - but why change what works?) and this communication is "machine-local". So, yes, a publisher service needs a transport service to be running on the same machine.

You can also fine tune the number of threads that the publisher and the transport will use for rendering and transporting in the MMC Snap-In. Beware that more threads != better performance. Finding the right balance between # of threads and performance is an art, with a lot of variables that may impact it - database performance, template optimization, network bandwidth between transport & deployer, etc.

On another note, I have learned a lot about the publisher by simply reading the output of tcmpublisher /debug (stop the windows service first).