Content Management System with a separate Publisher Server



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!


Posted 2013-04-10T14:37:18.110

Reputation: 686



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.


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

Nuno Linhares

Posted 2013-04-10T14:37:18.110

Reputation: 27 884

perhaps good to mention that adding yet another publisher using the same process is just as easy to double the publishing power again (or even just starting the publisher service on the CM box to deal with a temporary high publishing load). As Nuno mentioned the publisher services are already designed for dealing with multiple instances out of the box. – Bart Koopman – 2013-04-10T15:42:47.877

2Perhaps also worth mentioning queue notification. When an item is queued for publishing (on the editorial CM server) a UDP message is sent to any CM servers that are running a publisher and configured for this (on by default). This informs the publisher that there are tasks on the queue to be processed, and removes the need to wait for the polling interval before the queued item is picked up. – Dominic Cronin – 2013-04-10T15:49:33.023

1Thanks Nuno for your quick response. I really appreciate your time. Thinking in others scenarios I wonder if it would be possible (I have not seen anything about that in the documentation) to scale out also the transport service? Thanks again! – DanielGLB – 2013-04-10T16:33:30.793

@BartKoopman excuse me, I am not sure what you mean by "another publisher using the same process", it is about multi-threating? Set another publisher server? Thanks again! – DanielGLB – 2013-04-10T16:48:25.050

Thanks @DominicCronin, I really love this site. UDP message... great information! Seems to be much more optimized for dealing with publish queue (helps decrease latency times) like you have said. – DanielGLB – 2013-04-10T16:54:24.313

I meant using the same process of installation as Nuno described, sorry that wasn't very clear. So I was referring to adding an extra publisher machine indeed. – Bart Koopman – 2013-04-10T17:13:34.613

Thanks @BartKoopman. About the transport service in this scenario it would be possible (and recommended) to place next to the publisher service (in the same machine)? – DanielGLB – 2013-04-10T18:30:17.843

If I remember correctly the transport service is connected to the publisher, so every publisher machine gets its own transport service as well. – Bart Koopman – 2013-04-10T18:52:07.323

That's what I thought too. In fact this relationship is shown well in the server manager>Configuration>Services when start, stop or restart one of them (for example stop transport service causes the publisher service to stop too). So, in any case, both services should run in the same machine? – DanielGLB – 2013-04-10T21:35:16.490