What's the use of the publisher site?

Question

does anyone know what's the use of the publisher site? I imagine it has to do with the publishing but I'm not really sure:

<site name="publisher" domain="sitecore" enableAnalytics="false" enableWorkflow="true"/>

thanks

Answer 1

The fast answer is that the publisher site is used for publishing related jobs. But, you probably already knew that.

Why is publisher used in Publishing?

When one pulls the covers back a little on the Publishing process, it's revealed that Publishing utilizes the JobManager to manage publish processes. This is to allow for asynchronous processing to occur within the worker process. This allows Sitecore to perform other tasks and still be able to serve up a web request to an incoming http request.

To understand why the publisher site exists is to understand how JobManager works. JobManager utilizes Sitecore.Context to build a pseudo Sitecore Context that the job runs as. Part of this sets Context.Site to a certain site. Essentially providing swim lane for other jobs to process simultaneously. This also allows for priority and preference over other Job tasks.

There are actually two other sites that spin off Jobs in addition to publisher.

• Publisher - For Publishing
• Scheduler - For Scheduled Task Agents
• System - For System based jobs.

These sites sit at the bottom of the Site Definition because of how Sitecore's site resolution works with regard to most specific to least specific ordering. That's generally why the website site is listed last and right before these three classes.

Last but not least, JobManager only allows 1 job per site to run at a time. If you've ever encountered the Publishing: Queued message, this is because someone else currently has a publish job running. Your publish job has been added into the queue for JobManager and will be ran, but in a background context that you can't see.

Looking Behind the Curtain

To see an example of this publisher site in action, look no further than the Publisher.PublishAsync() class. Below you can see how the method is creating JobOptions() that includes the site to run the Job as.

public virtual Job PublishAsync()
{
  this.AssertState();
  JobOptions options = new JobOptions(this.GetJobName(), "publish", "publisher", (object) this, "PublishWithResult")
  {
    ContextUser = Context.User
  };
  options.ContextUser = Context.User;
  options.AfterLife = TimeSpan.FromMinutes(1.0);
  options.AtomicExecution = true;
  options.ExecuteInManagedThreadPool = Settings.Publishing.ExecuteInManagedThreadPool;
  options.CustomData = (object) new PublishStatus();
  Job job = Context.Job;
  if (job != null)
    options.ClientLanguage = job.Options.ClientLanguage;
  return JobManager.Start(options);
}

Answer 2

The publisher site is responsible for actually running the publishing of your content.

Simple Answer

The simplest answer that I can give is that this is one of the ways that Sitecore implements multi-threading/parallel processing in SXP. Since publishing processes in a separate site, you don't have to worry about your publishing operation interfering with the rest of your instance's ability to function.

Sitecore actually uses this same technique for its scheduler. The scheduler is another site that is used to run scheduled jobs off in a separate set of threads.

High Level - How publishing works

The way publishing works is that the items to be published are added into a queue that is processed when a publishing operation is triggered. Publishing operations can be triggered from the UI directly, from Workflow, from Scheduled Tasks, or from custom code.

Once a publishing operation is triggered, a separate site is used to keep the publishing processing in separate threads from the rest of the site(s) in the environment. This way, your other sites, including your client-facing site (if you have a single-server/stand-along instance) are not (as) affected by the publishing operation.

This approach works pretty well and is anecdotal to the way that multiple sites sharing a single Application Pool works. Basically, there are a certain number of threads available up front and those threads are distributed between the various sites that run on the app pool.

The Caveat

If an operation on one site becomes too taxing, it can risk the performance of the other sites. This holds true for both Sitecore sites, including the publisher, and sites that share a single app pool. Sitecore does its best to mitigate this risk and allows you to configure many settings related to thread use, but nothing is perfect.

Have you ever wondered why your site sometimes slows down or even locks up when doing a full-site publish operation? Now you know why.