I’ll be continuing the Baby Steps to SOA topic next week, but for this week I’m jumping back into the world of Sitecore.  I’ve just spent the past few weeks performance tuning another project, and there are so many rabbit-holes one has to jump down to find the culprit of a performance issue.  Networks, databases, memory leaks, caching, bad code, integration bottlenecks… so many variables that can lead to a Sitecore site performing poorly under load even when it seems all the Sitecore configurations are correct.

Helpful Resources

While trying to track down the cause of my particular problem, I was able to find a few great resources that I’ve pulled together here, along with a few tips.

1. 27 Tips on Configuring Sitecore for Performance, Scalability and Security
   My colleague Glen McInnis gathered together a lot of recommendations from Sitecore guides and cookbooks and collated a list of things to do to ensure a solid installation.
2. A Going Live Checklist for Sitecore Websites
   Not as many tips, but some great starting points and the article also links out to several other good reads.
3. Tricks and Optimizations for your Sitecore Website
   This post has some very specific details on configurations that can be made to tune performance.

Eliminating Variables

It is possible that with all the tuning complete the site still responds poorly.  Sometimes, this may be a hardware or networking issue, and sometimes the issue might be within the code itself.  To help track this down, try the following:

1. Create a static HTML page that has the same markup as would normally be rendered by one of your poorly performing pages.
2. Install this page on the same webserver on the same domain that is performing poorly.
3. Load test this page directly with your favorite load testing tool.
4. Analyze the results and see if the performance issue still exists.

If the analysis still shows problems even when Sitecore is not involved in the delivery, you can be sure the problem resides somewhere in the hardware or network, and not in the code.  If performance is good, then you know that something in the code is the problem and the network and hardware can be ignored as a source of the issue.  Either way, this won’t be the end of the analysis, but should allow for standard network, hardware, or code performance tweaks to begin.

What’s Next?

If the problem is in the hardware, tools like PerfMon and Fiddler can help you track down the issue.  If the problem is in the code, using the Sitecore debugger and admin Stats page can help you find troublesome sublayouts