4

I'm looking for a rule of thumb based on some real-world experiences on whether to use Sitecore Publishing Service or not.

Things that probably need to be considered:

  • number of items
  • number of item language versions
  • how frequently items change
  • number of publishing targets
  • latency from the CM server to the publishing targets

I would presume a combination of the above would lead to considerable time savings if Publishing Service were used, just looking for some rough numbers?

3 Answers 3

6

My rule of thumb is: Use it only if you really need to.

Publishing Service (SPS) improves publishing speed a lot. It's super fast in comparison with the built-in publisher. However, it has its draw backs. Besides adding complexity (one more service and module) to the solution, it has had its issues over the years. I've run into so many bugs in it. Though some of them have been fixed now, there are plenty left.

The built-in publisher is quite db chatty, so number of items and versions do count a lot. Latency plays a big role here as well. From what I remember, the built-in one also publishes to one target at a time while SPS publishes in parallel. SPS also publishes in bulk, reducing latency issues as well.

Even though SPS comes with a new UI etc., it's really only about speed. It also limits your ability to extend the publishing process (which should be avoided anyway).

If you're at a scenario where SPS would help a lot, you could actually have it sort of installed in "parallel". If the core:/sitecore/system/Aliases/Applications/Publish item is renamed to something else, it will disable SPS and you can run with the built-in one. Thereby you can compare the two and also evaluate if SPS does its job properly.

When comparing the two, it's also good to know that some operations related to publishing are executed async. For example index updates, item events, cache clearing etc. With the built-in publisher, this is mostly not seen. This is because those events are usually executed faster than it takes to publish an item. When running SPS, all those events still occur. This means that the SPS UI may say a publish is complete, but in fact a lot of events are still being executed in the background. This can lead to frustrating among editors not seeing their recently published updates and maybe trigger more publishes etc.

I wrote some notes about this a few years ago. It's a bit dated but most of it is still relevant: https://mikael.com/2019/07/learnings-from-a-year-of-implementing-sitecore-publishing-service/

1

I would say the Publishing Service can be especially beneficial under these circumstances:

  1. Huge and Frequent Content changes: When there is a dedicated content team for making frequent and a lot of content updates it may make sense to speed up the Publishing Service
  2. New Project: When there is a new project with a lot of content, it may be sensible to have a Publishing Service to avoid the Content Editor being blocked due to Publishing activities.

To be really honest I feel Publishing Service is an add-on rather than a must have. The native built-in Sitecore publisher has improved quite a lot. Both publishing and indexing tasks can even be scheduled if need be. Bulk publishes like publishing the home node or entire templates folder for example can be avoided.

1

Advantages/Benefits of Sitecore Publishing Services

  • Better user experience
  • Support Multiple targets
  • REST APIs to control the publishing service
  • Support bulk publishing that helps to publish bigger Sitecore packets in lesser time
  • Having dedicated application for publishing that improve the CMS performance as well as publishing job performance
  • Can be tracked who have triggered the publishing job and what was the options selected while triggering the publishing job
  • Can be checked the status of the publishing job

For more around this, you can visit to my blog here: http://www.tekkishare.com/pages/configure-sitecore-publishing-service

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.