Improve performance while publishing using core servcie

Question

I gotta question in mind while developing a app which does huge publishing using core service. I wanna know which way is the best and highly performant. I can call the Publish method with all the item uris for a target (so 2 calls for 2 targets) or Call the publish method each time for an item. We have only 2 CMS severs (2013 SP1) and expecting around 300 to 400 items be published through this app at a time. Let me know which option suits me the best.

In addition to this, any experiences and things to be taken care off while publishing using core service would help. Thanks!!

Answer 1

When publishing it always makes sense to group as many items as you can together in a single Publish Transaction, to benefit the most from the transaction item caching that is done for you in the background.

One thing to keep in mind here, is that publish actions to different Publication Targets will always be rendered separately (they will show up as a separate transaction in the queue).

So combining this information with your question, you mention you have two CMS servers, so I'm assuming you mean a scaled out CMS with a Publisher service running on each one. Depending on how your Publishers are configured they might have a single rendering thread, but they might also have multiple. Whether you call the publish method with both targets or two times with a single target won't make a difference here, since in the end, you will always end up with two different transactions anyways (one for each separate target).

You have to keep in mind that since you only have two publishers and the CME is also running on that same machine, you might want to leave the settings of those machines as default as possible (single threaded publishing) to always keep some CPU and memory available for the UI and core processes.

If you would have dedicated publisher machines, you could investigate is if it would be worth splitting up the large publish action into smaller transactions. This would be particulairly beneficial, if you have multiple publisher threads configured and notice you still have some CPU power to spare when the publisher is rendering that single large transaction. But that all comes down to tweaking the performance, so fiddling with how many threads for the Publisher seems to work best with the majority of your Publish Transactions (large and small).

Answer 2

As with all performance work, your best option is to measure rather than guess. Tridion already provides a natural grouping for publishing items, in that you can publish a structure group, (or indeed a publication, but that's probably too big a bite). Assuming that this grouping matches your required functionality, this would give you a less "chatty" core service programme.

If your list of items is less structured, you might also look at grouping them using bundles.

Bart mentions the benefits of caching within a publish transaction, but you can also get a big win from Tridion's resolving within a publish transaction. If you publish lots of small transactions, and each one resolves the same extra items, you can imagine that having everything in one transaction involves less actual publishing. (Also - I may be wrong, but I think that even though each publication target in a transaction needs its own render, the resolving phase only takes place once.)

Ultimately - your mileage will vary - so I'd suggest coding up two or three such approaches and testing to see how they work with your data. Someone else's data will probably have a different sweet spot.