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!

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


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

  • 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. Commented Apr 10, 2013 at 15:42
  • 2
    Perhaps 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. Commented Apr 10, 2013 at 15:49
  • 1
    Thanks 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
    Commented Apr 10, 2013 at 16:33
  • @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
    Commented Apr 10, 2013 at 16:48
  • 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
    Commented Apr 10, 2013 at 16:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.