Things to Consider for SharePoint Performance

SharePoint performance is a function of a number of factors. Some are obvious, some are less obvious, some are easy to address & others are more difficult. One good place to learn more about performance & capacity planning is the resource center.

Let's start with some of the obvious. SharePoint is a web application and performance, simply put, is the time it takes for an end user to see the expected result from the time he/she clicks on a link or types in an address in the browser. Like all web applications, even if the server (SharePoint) is "fast", if the size of the page/document is large or network latency is poor, performance will be negatively affected. Reduce the footprint of a web page and browser requests required by really paying attention to the number and size of images and css/javascript files.

In fact, recently, I came across a really interesting solution: RPO (Runtime Page Optimizer) from Aptimize. For example, take a look at Ian Morrish’s SharePoint site – www.wssdemo.com. The site runs at better than 150% improvement and incredibly speeding up his “Top 100 best looking SharePoint websites” page by 400%.  See for yourself by using a switch to temporarily disable the RPO. With RPO: https://www.wssdemo.com/Pages/topwebsites.aspx and without RPO:   https://www.wssdemo.com/Pages/topwebsites.aspx?rpo=off. According to Ed Robinson, the CEO of Aptimize, the real breakthrough is request combination at runtime – by combining the JavaScript, CSS and images into fewer files then caching them, both browser and server simply do less work. You can get a free trial from www.getrpo.com.

This trick works to speed up web content, but if you are looking to reduce the footprint of Office documents, consider converting documents to OpenXML. OpenXML can reduce file sizes by more than 50% and there are tools to help with this migration.

Caching also helps with performance. Groove is great because it downloads files in the background similar to how Live Mesh works for those of you who have used it. While client caching is helpful, WAN acceleration also helps with poor network latency especially in branch office solutions. There are a number of WAN acceleration partners out there that can be considered; some market themselves as specific SharePoint accelerators; some just web accelerators. WAN acceleration is an easier and at times more effective solution than replication. Many of these WAN accelerators use compression techniques similar to IIS compression - something else that helps with network latency.

When you've addressed some of the more obvious network latency & page footprint issues, it's important to optimize server performance. Assuming the server is the problem, after you've ruled out the previous issues, it's important to understand your options. For starters, always architect your solution properly; it's imperative that you follow the best practices as prescribed by the SharePoint engineering team - 64-bit hardware, CPU power & a decent amount of memory is a must. As important it is to scale up, consider scale out options as well if your web server seems to be a bottleneck for the load you are getting.

Along with hardware, also make sure you have the latest software installed in the box. At a minimum, on top of SharePoint RTM, you should have SP1 & the Infrastructure Update installed on the box. There are specific feature areas that work much better & faster like content deployment.

As mentioned earlier, b/c SharePoint is a web application, it's important to tune IIS to perform optimally. The Best Practices for Team Collaboration Sites highlights some best practices in step #6. Also, if you have the option, I recommend using Windows Server 2008 as the underlying OS for better IIS performance. There are some other benefits of WS08 that I've listed here.

Good hardware to scale up and scale out helps, but isn't the only thing to consider when architecting your solution or trying to speed it up. SharePoint stores its data in SQL so it's really important to plan and monitor SQL. I recommend checking this whitepaper out for detailed information. SharePoint allows you to separate your content databases so it's important to plan appropriately for runtime performance as well as for operational efficiency during backup and restore. For example, you do not want to have terabytes of content in one content database; it will become the bottleneck irrespective of how many front end web servers you have. Instead, you want to break up your content into a number of content databases to distribute load. Also, where it makes sense, especially for web publishing portals, you should use ASP.NET Output caching & BLOB caching to minimize database access.

If your web front ends are in good health and you have the latest & greatest patches installed, your SQL is well planned, you still need to make sure your Information Architecture is healthy. The 2000 items per view is a best practice that has been outlined in a number of places. As mentioned earlier, limiting content database sizes is important and can be achieved by setting quotas and using other governance levers. The Governance Resource Center has a number of whitepapers that walk through how to work through your various options. There are number of great whitepapers listed, here are a few to look over:

Windows SharePoint Services manageability controls

Supporting information architecture with Windows SharePoint Services manageability controls

Implementing Windows SharePoint Services governance

Another really solid whitepaper is the one written by Sean Livingston that really talks about how to setup SharePoint in an enterprise and plan for customizations and work with your different business units. Sean was one of the architects for the SharePoint deployment at Microsoft. He is now part of the core product group using his real-world experience to make the next version of SharePoint even better for IT Professionals. Here's a direct link to the whitepaper: SharePoint Products and Technologies customization policy.

The last thing I'll mention is custom code. You can do everything right, but poorly written code can negatively impact performance. While this is not specific to SharePoint, there are some things specific to SharePoint that each developer must pay attention to. One specific issue I see very often is developers not properly disposing SharePoint objects: https://msdn.microsoft.com/en-us/library/aa973248.aspx. This causes performance to degrade over time and it's very important to pay attention to. Of course, beyond memory disposal, there are many other ways custom code can slow a server down, so it's very important to pay attention. Poor code can not only affect one user session, but slow down the entire server. As I mentioned in a recent post, SharePoint developer experience is required, so make sure your developers have real world experience and test their code (not just with one user, but a simulated load) before deploying it to production. Of course, there is the obvious - don't take shortcuts to improve performance. Don't read or write to the SharePoint database - it's simply not supported and it's a bad idea. Good developers can take advantage of AJAX/Silverlight to "improve" performance with less post backs to the server.

Comments

• Anonymous
  October 22, 2008
  Top News Stories Innovative-e, Inc. Managing Partner Publishes SharePoint Book to Help Companies Organize