Senior Product Manager, Microsoft

Menu

Bill’s 5-min. SharePoint Performance Recommendations

Performance recommendations and guidance is something I receive comment and question on quite frequently, typically in hallway conversation or in passing at conferences – so in the spirit of those occurrences I’ve decided to compile a quick list of SharePoint performance recommendations that can be conveyed verbally in five minutes or less.

Governance

Do limit the number of site collections/content database, I’m adamantly opposed to the “airline booking model” and much prefer what I like to refer to as the “accounting model” of database management, for example, if you know your maximum allowable site collection quota will be 5GB, and would like to keep your content databases at 100GB, logically you can host no more than 20 site collections per database and while this can result in a large number of content databases, you avoid site collection proliferation…with this model you should also take into account growth and set aside 5-10% to support schema changes, etc. *Remember to size your content databases to the desired size as they are created – SharePoint Products and Technologies will provision the content database at xMB and configure growth to occur incrementally at 1MB chunks. A smaller number of site collections in a content database not only benefits efficiency of operations, but can also mitigate the exposure of any locking that may occur within that database to a small subset of users as opposed to a large population.

Caching and Compression

Do consider and encourage site output caching, BLOB caching, and/or HTTP compression where possible – do be sure to closely monitor processor utilization where using HTTP compression.

Do consider proactively addressing garbage collection on 64-bit machines, custom code and other external factors can potentially litter the address space with unintended assemblies and permanent memory allocations, while most is addressed with “managed memory” you may still experience conditions in which there is a Web server response delay until the buffer can be moved in memory. Depending on the nature of the code you should consider monitoring .NET CLR Exceptions, Memory, and Loading Performance. So you are faced with the decision to either proactively manage consumption through scheduled recycling, or monitor garbage collection activity dynamically and recycle when garbage collection activity has exceeded a pre-defined threshold – of these decisions the former implies configuring an arbitrary memory threshold and the latter understanding your individual requirements based on Web server configuration (I.e. resident services, hardware, load, etc.) which is the preferred methodology since you in effect will maximize the available memory while ensuring your Web servers remain responsive and mitigating availability issues as the result of too frequent a recycle in the case of configuring or designating a threshold.

Storage design and database architecture are other potential performance bottlenecks, carefully consider database distribution – where clustering, databases should be distributed across two or more instances – and with the underlying storage, provide as many spindles as possible to your data LUNs.

Authentication

Do consider Kerberos authentication where possible, significantly reducing the number of round trips per page versus NTLM.