Scaling your Sitecore Solution

Recently there was a question on StackOverflow asking about improving the performance of their Sitecore implementation.

Here are some things you can consider without changing overall architecture of your deployment

CDN to offload media and static asset requests

This leaves your content delivery server available to handle important content queries and display logic.


Configure and use Sitecore’s built-in caching

This is from the guide:

Investigation and configuration of the Sitecore Caches is broken down into multiple tasks. This way each task is more focused and simplified. The focus is on configuration and tuning of the Sitecore Database Caches (prefetch, data, and item caches.)

For configuration of the output rendering caching properties, the customer should be made aware of both the Sitecore Cache Configuration Reference and the Sitecore Presentation Component Reference as to how properly enable and the properties to expire these caches.

Check out the Sitecore Tuning Guide

Find Slow Queries or Controls

It sounds like your application follows Sitecore best practices, but I leave this note in for anyone that might find this answer. Use Sitecore’s built-in Debug mode to identify the slowest running controls and sublayouts. Additionally, if you have Analytics set up there is a “Slow Pages” report that might give you some information on where your application is slowing down.

Those things being said, if you’re prepared to provision additional servers and set up a load-balanced environment then read on.

  1. Separate Content Delivery and Content Management To me the first logical step before load-balancing content delivery servers is to separate the content management from the equation. This is pretty easy and the Scaling Guide walks you through getting the HistoryEngine set up to keep those Lucene indexes up to date.
  2. Set up Load Balancer with 2 or more Content Delivery servers Once you’ve done the first step this can be as easy as cloning your content delivery server and adding it to your load balancer “pool”. There are a couple of things to consider here like: Does your web application allow users to log in? So you’ll need to worry about sticky sessions or machine keys. Does your web application use file media instead of blob media? I haven’t had to deal with this, but I understand that’s another consideration.
  3. Scale your SQL solution I’ve seen applications with up to four load balanced content delivery servers and the SQL Server did not have a problem - I think this will be unique to each case depending on a lot of factors: horsepower and tuning of SQL Server, content model of your application, complexity of your queries, caching configuration on content delivery servers, etc. Again, the Scaling Guide covers SQL Mirroring and Failover, so that is going to be your first stop on getting that going.

These options are really just the starting point for getting this set up. There are a number of great resources out there, check out John West’s blog posts on this topic and you’ll find a wealth of information.