5

We have started using bundles and one thing which I have noticed is that the whole bundle is processed (rendering etc.) only on one publisher. We have a fully scaled architecture with separate publisher and CM servers. So, earlier, when items were scheduled for publish at the same time, the load was distributed on all the publishers, but with bundles the whole bundle with all its items is processed on one publisher which effectively increases the time to publish by a simple multiplying factor (# of publishers).

For e.g., earlier if 24 pages took 2 minutes with 6 publishers, now it takes 12 minutes for the same number of pages (in a bundle) since they are all processed on the same publisher.

Question:

Is there a way to configure or has anyone got any solution or even a workaround to set the items to be distributed across the publishers, so that we can leverage the fully scaled publishing architecture (use all publishers)? This is definitely causing issues since the same # of pages which used to take x minutes for publish is now taking x * #of publishers minutes with the bundle feature.

With new features I am definitely not expecting a worst (if not better performance in any aspects in the tool), but this stands as an odd one out. I hope I am not wrong in my expectations!

We are on Tridion 2013 SP1.

Improve this question
1
  • 2
    Unfortunately (for your expectations), it will always go through a single transaction/Publisher. The main use case for bundle publishing was consistency rather than performance - if one item in the bundle fails, then nothing gets published, and this cannot be enforced if you split the publishing job across multiple transactions.
    – Nuno Linhares ♦
    Commented Jul 21, 2015 at 7:51

2 Answers 2

Reset to default
3

This is happening because a Publisher will pick up a job off the queue and fully process it. By publishing a bundle you are creating 1 job which resolves to many items, but all those items will be rendered by the 1 publisher. Technically, performance is not worse, but as you have introduced bundles (they didn't exist before) your use case has changed and the publishing configuration is not optimised for that scenario.

It's not possible to distribute rendering of a single job across Publishers.

It may be possible to break the job up into multiple items with an Event Handler. That would also help with your package size issue, as the items would be rendered and transported separately.

Improve this answer
9
  • Well if I break the job into single items, then it is extremely difficult for the users to know whether this item is from the bundle or not and it shows as a separate transaction. Also, breaking it into any other unit other than single items is going to have an impact since the bundle will not be distributed across the publishers. As I said, I don't expect performance going negative with any features, but this is noticeable and is being felt by the users.
    – Vipin Kothari
    Commented Jul 20, 2015 at 21:13
  • 1
    Performance cannot degrade for a feature that did not previously exist. If bundles existed in 2011 I expect that performance would have been practically the same for the reasons outlined above. Publishing throughput is different now because the conditions of the test have changed; Users are publishing things differently. Given that what you want to do is not possible, you'll need to consider alternatives. What did the users do before bundles existed? Could they use bundles for organisation, but select all the items inside them when publishing? Can you change your publishing configuration?
    – David Forster
    Commented Jul 20, 2015 at 21:43
  • Can they create smaller bundles?
    – David Forster
    Commented Jul 20, 2015 at 21:44
  • 1
    Sounds to me that the easiest solution to your problem is to simply not use bundles? It's a trade-off decision after all: publishing the bundle will guarantee consistency (as the entire bundle is published as a single transaction) but publishing the individual items will give better performance. Pick one. If you prefer performance and don't care about transactions write an event system that splits the publish transaction into individual items.
    – Bjørn van Dommelen
    Commented Jul 21, 2015 at 13:50
  • 2
    I would also like to point out that in theory using a bundle to publish will improve performance due to increased benefit of session caching (all rendering will take place in the same session for all items in the bundle). Just because an individual bundle takes longer doesn't mean lower performance; publish 10 bundles with 20 pages each and you'll see this is faster than publishing 200 separate pages...
    – Bjørn van Dommelen
    Commented Jul 21, 2015 at 13:53
1

The only crazy idea i can think of is to have Event System which can be executed on bundle publish. It can destroy bundle publish transaction, and send all items separately to publishing. The only benefit with this approach is for users to send one item to publish, but it results in X number of separate transactions to be picked up by how many publishers, but honestly, I wouldn't even go there!

What I would suggest to you is following:

  1. educate your editors. They must be aware that sending one bundle with 1 or 2K items will result in long transactions. Bundles should be used for publishing similar, related items, not being lazy and sending all.
  2. Analyze your content. Try to identify if some items don't need republishing/publishing. You would be amazed how many items don't need republishing and are republished just so.
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.