10

This section in the online docs (login required) about publishing failing talks about resolving problems if things get stuck waiting for the Deployer.

In particular:

The value of Workers depends on the number of CPU cores on your server, and if this number is too low compared to the window size you configured, items will be placed in the queue.

Our deployer is configured as per the default:

<Location Path="D:\tridion\incoming" WindowSize="20" Workers="10" Cleanup="true" Interval="2s"/>

But I was wondering, is this default based on a single core CPU - if not, how many CPU cores is it based on?

I know the general advice seems to be to only adjust these settings when you actually see performance problems, but given our server has 6 CPU cores could I increase the Workers number to take better advantage of our hard ware?

Is it as simple as Workers x CPU cores?

Cheers

Improve this question

1 Answer 1

Reset to default
6

The number of worker threads is indeed the number of deployment packages the deployer will process in parallel. While your hardware might be able to support more, adding more will not necessarily improve performance unless you are already having situations where you have more than 10 packages (=publishing transactions) to be deployed at the exact same time.

I don't actually know where the number 10 comes from :) but I can only assume that's what was found safe to use on a normal deployer configuration.

These numbers should also be tweaked together with transport and publisher render threads. Increasing this number without increasing the throughput of your publisher(s) will make absolutely no difference.

And, just like the render threads, it is an art form to find the right balance. Sometimes, less threads will actually make the system faster by reducing bottlenecks and contention points (typically, your database).

It's never as simple as workers x CPU cores due to all the factors involved. Some transactions are very small (1 DCP) other transactions are very big (full publication). 2 transactions may contain updates to the same item, so a lot of work needs to be done by the deployer to avoid database locks. And the list goes on.

My advice: if it's working now, don't tune it. And if you really feel like tuning, then start by tuning publisher/transport before moving to the deployer.

Improve this answer
2
  • Thanks Nuno. My reason for asking stems from in our case, under "normal" conditions everything is fine, but every so often the client will publish a complete site section of around 1200 pages. I suggested using the Page Publisher Power Tool as this gives more feedback via the queue and doesn't bomb the whole transaction if one thing fails but recently everything seemed to "lock" and I had to restarted Publisher, Transport and Deployer.
    – Neil
    Commented Nov 6, 2013 at 15:08
  • You could try increasing the Windowsize (# of packages the deployer will keep on waiting state) without changing the worker threads, this will at least change when will the deployer start complaining to the transport that it has enough work already...
    – Nuno Linhares ♦
    Commented Nov 6, 2013 at 15:23

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.