One of the Sitecore projects is running on Azure PaaS. I use Sitecore 9 update 1 medium size (1 cm, 1 cd). The publishing speed is very slow after exceeding 10k items or more (I have around 200k items, it takes 1 day to complete the publishing).

I've tested the same publishing scenario on a clean PaaS Sitecore instance and it's still slow If you compare it with your local dev or the development on-premise Sitecore instance.

I have tried the following to increase the publishing performance with no luck:

  • Scaled out the CM app service.
  • Scaled out the databases (core, master, web). I have set up the DTU to 1000 for testing purposes and I can see the site is getting faster but still the publishing very slow after reaching 10k items.

Right now I'm switching to Sitecore Publishing Service, but I would like to know what is the reason for the performance issue especially all of the databases and the web app services located in the same region with great specs.

  • What is your memory consumption during publish? What is the max DTU? Oct 11, 2018 at 13:01
  • How long is it taking on your local machine? Oct 12, 2018 at 5:26

1 Answer 1


I have put together a config from the info on this good answer for Sitecore 8.

Have a try at applying the following config on both CD and CM:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
      <!-- This setting is changed from the default value to enable parallel processing of publishing candidates.
           The value '4 ' is specified here as an example.
           The optimal value for this setting depends on your solution and on the CPU capacity of the server that runs the publishing operations.

           For example, if the system architecture leverages a dedicated publishing instance with plenty of CPU capacity, this setting can be
           increased even further.
           On the other hand, on solutions where publishing is run on an authoring server that is already running a high load, changing this
           setting to a non-default value may cause system stability issues. 
           We highly recommend that you perform publishing tests with the expected load before you change this setting in production environments.

           Please remember that your database server's CPU and disk capacity may need to be adjusted to accommodate this setting.
      <setting name="Publishing.MaxDegreeOfParallelism">
        <patch:attribute name="value">4</patch:attribute>
        <!-- This processor performs parallel processing of publishing candidates.
             The Publishing.MaxDegreeOfParallelism setting specifies how many concurrent operations can be run. -->
        <processor type="Sitecore.Publishing.Pipelines.Publish.ProcessQueue, Sitecore.Kernel">
          <patch:attribute name="type">Sitecore.Publishing.Pipelines.ParallelPublish.ParallelProcessQueue,Sitecore.Kernel</patch:attribute>

I have tested this on 9.0.1. I get the following results on a full republish:

  • Local machine - config not applied - ~5 items/s
  • Local machine - config applied - ~1000 items/s

  • Azure PaaS B3, 50 DTU master 50 DTU web - config not applied - ~2 items/s

  • Azure PaaS B3, 50 DTU master 50 DTU web - config applied - ~90 items/s

It hits 100% DTU usage, but CPU usage is not quite maxed so I think the 50 DTU is the bottleneck in this example.

From my calculation you are currently getting ~2 items/s which is in line with what I was getting before adding the config. If you can achieve ~100 items/s then you should be able to publish 200,000 items in ~34 minutes.


I've updated the config and removed a lot of the settings as I did have some issues with it on 9.1. Also the main setting to tweak is the Publishing.MaxDegreeOfParallelism as the others didn't have much effect from my testing.

  • I'm not trying to be funny, but why wouldn't this be default? What are the downsides?
    – geedubb
    Jul 29, 2020 at 18:30
  • 1
    @geedubb your guess is as good as mine. I don't see any downsides. Jul 31, 2020 at 1:10

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.