Tilting at SharePoint Performance Windmills

As anyone who has ever heard me speak or had the misfortune to be cornered by me at a SharePint event knows, I’m a big proponent of implementing best practices for optimal SharePoint performance, both from an IT infrastructure perspective as well as custom development. Unfortunately, this is a tricky area with lots of gotchas – there are so many variables that impact SharePoint performance you almost need a roadmap to figure it all out. One of the most common issues we encounter in enterprise deployments is a default configuration that was installed way back when SharePoint was a departmental solution and, after growing and assimilating everything in its path like the Borg, has become an unruly monster that is slow and unresponsive.

Over the years we have seen just about every worst practice that you can imagine when it comes to poor performance – loading up a single server with tons of services, doing massive crawls within a single search scope, starving WFE’s with minimal RAM, putting database servers on shared LAN segments – you name it, we’ve beat our head against it. Those of us who live this stuff day in and day out, and who have been around since the wild west days of SharePoint (which, in retrospect, was only about five to seven years ago even though it seems like several lifetimes), take for granted all the guidance that exists around this topic. But the truth is that most business don’t have time to deal with all of SharePoint’s nuances and intricacies – they just want it to work, and rightfully so. Despite all the best intentions of community contributors over the years, who have devoted countless hours to spreading the performance gospel, there still exists a deep divide between what should happen as a matter of course and what actually happens in practice.

As a means to bridge this divide, we at BinaryWave undertook the task of organizing our collective experience solving SharePoint performance into a set of repeatable practices that we feel represent the most common and easily solvable issues. Our first step was to create Sonar (since acquired by Idera and relaunched as SharePoint Performance Manager), as a means to objectively measure and isolate underperforming page objects. Although this had a tremendous impact on our thinking around some of the really difficult issues relating to the MOSS request processing pipeline and object model in general, we also realized that there are a number of issues which don’t easily lend themselves to a product-based approach; in many cases you simply need an experienced set of eyes to look over everything and synthesize all the environmental factors into a targeted root-cause analysis. To this end, we conceptualized a service offering which would provide customers with hands-on guidance and optimization recommendations specific to their environment.

We have just announced the culmination of this effort as our SharePoint Performance Optimization service. The offering is primarily targeted at enterprise customers with a significant investment in SharePoint products and technologies but we hope to expand it down-market to SME customers as well. It is our hope that we can make an impact by reducing the amount of performance headaches that customers have endured by making it easy to identify, isolate and optimize their deployments.

I’d love to hear feedback from the community on the most common performance problems that people encounter in their day-to-day SharePoint existence. With any luck we’ll be able to disseminate this information via public forums and keep this discussion in the forefront of everyone’s mind. The more people who talk about performance the better off everyone will be. So feel free to comment, write a blog post, or otherwise publish your thoughts on this subject. I’ll link to as many of them as I can and you can rest assured that I’ll keep banging the drum whenever I get the chance. I might be a rhythmless Redneck but at least I can make some noise!