4

I wanted to know if there is any recommendations/best practices for how many maximum threads we should use for rendering on Publishers. I am looking at modifying the renderThreadCount attribute in Tridion.ContentManager.config to allow multiple rendering threads and hence wanted to check on best practices or experiences of using multiple threads and possible side effects if any

<threading renderThreadCount="2" deployThreadCount="2" />

I did not find any details on the same in sdl live content.

We have a fully scaled architecture having 6 publishers and we are using Tridion 2013 SP1

Improve this question

3 Answers 3

Reset to default
4

As mentioned by Nuno's answer to Content Management System with a separate Publisher Server, more threads does not always 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.

I normally start by determining the number of processors and cores available, and then leave one core free per processor.

For example, if you have a (standalone) publisher with two quad core processors (eight cores in total), then I'd start by using six threads for each (i.e. <threading renderThreadCount="6" deployThreadCount="6" /> ).

The total number of cores on the server are obviously then shared between all publishing (and Operating System) activity on the server (resolving, rendering, transporting, etc.).

This is just a 'rule of thumb' that I have used in the past, and seemed to provide consistent publishing performance. However, as Nuno suggests, you may need to do some monitoring and experimenting with these settings.

NOTE: I cannot remember where I heard this 'rule of thumb'. I'll try to find the links and add it here.

Improve this answer
3
  • That rule of thumb probably came from an infrastructure consultant, possibly said during a sys admin training (who knows it could have been Nuno in those days ;o). It's not written down in any official document for as far as I know, but you are correct in how to interpret and use it.
    – Bart Koopman
    Commented Mar 10, 2015 at 14:13
  • One additional remark which can be said is, that I've seen environments where it worked out better to double the amount of threads vs. processor cores, but also those where the exact oposite counts. It's really related to how the system is being used (publishing single Pages vs. Publications or Structure Groups) and what Template code is used.
    – Bart Koopman
    Commented Mar 10, 2015 at 14:17
  • @ Jonathan, I like your idea and thought process about the # of processors and their usage. Thanks others as well for sharing ideas. I will update this post with my answer once I do the change and see results. I am planning to use Jonathan's approach
    – Vipin Kothari
    Commented Mar 10, 2015 at 19:16
4

In addition to Jonathan's response above that the impact of increasing threads depends on a number of factors...

You can note that a task that consumes lots of CPU power and does not require I/O (such as calculating PI or prime numbers) then 1 thread per CPU will probably be best.

Where a task is bound to I/O - such as processing information from disk, you will likely increase performance by having more than one thread per CPU. In this case the disk access can take place while the CPU is processing information from a previous disk read (and as you probably know we're using I/O somewhat in our publishing processes)

Of course, there's context switching to consider also along with the expected speed of each transaction,

for example if your site is publishing

  • 100 x 100mb PDFs per hour versus
  • 100,000 x 100kb pages

you can guess these would have dramatically different requirements in terms of processing efforts on the system (and as Jonathan mentions, network throughput etc.).

Safe to say there is no golden answer and you'll only find the sweet-spot for the specific tests you run - so

  1. it's important to run tests and compare (this is no mean-feat)
  2. it's important to monitor 'what' and 'how' you publish over
  3. time to test if rendering/publishing speeds change over time

Do share your testing / findings so we can learn more ourselves.

Improve this answer
0

I have changed the setting to 2 threads per core and 4 threads per core in 2 different environments last week and so far it looks fine on both. I did a lot of publish tests and I did not see any issues in both. So, I am thinking of going with a cautious approach of 2 threads per core for now.

I have a related question though: I changed the renderthreadcount attribute but not the deployThreadCount as I was not sure what it is meant for. Can someone please throw some light on the same?

Improve this answer

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.