Search This Blog

Monday, March 7, 2011

How to improve Sharepoint Performance

Regardless of the framework and methodology you use in trying to understand your SharePoint performance issues, isolate their root causes, and resolve the problems, you need baseline data that reflects acceptable performance against which you compare data that reflects poor performance. You can obtain a baseline set of performance data either right after your initial deployment, during periods of acceptable performance, or from best-practice recommendations. If you have no basis for comparison, then you can use Microsoft published performance recommendations for various measurements, available at

Possible Root Causes
Possible Resolutions
High disk I/O activity on SQL Server
Large list operations, timer jobs, SQL maintenance tasks, backup, indexing, inadequate RAM, high I/O databases such as temp tlog, search, and content, placed on same disk or slow disks.
Separate temp and search databases in multiple files across high I/O disk volumes, increase RAM, use dedicated disks for transaction logs, defragment, and re-index databases weekly.
SQL blocking/locking
NIC configuration, large list operations, indexing/crawling jobs.
Do not use SharePoint Team Services Administration (STSADM). Use SQL backup, DPM, Litespeed, or SQL 2008 with compression, ensure fill factor is set to 70% on content databases, enforce 100GB growth limit.
Overall slow page loads
Compression not enabled. Caching not enabled or not configured. Large pages. Redundant SQL trips, underlying network issues.
Enable caching and compression, check page load times, and examine SQL queries and round trips, check NIC for Broadcom 5708 Chimney issues.
Long time to load full page
Improper SharePoint object handling in custom code, slow links, SQL blocking, timer jobs, Web part caching not enabled.
Resolve back-end bandwidth and response issues, dispose of objects properly, use 64-bit hardware or configure memory pool limits, delay downloading core.js.
Poor list performance
Large lists >2,000–3,000 items in a level. No indexing on lists. Underlying SQL Server issues. Too many columns.
Index on one or more columns, ensure SQL Server performance, keep fewer than 2,000–3,000 items in a level.
Long crawl and index times or indexing causing sluggishness
Large data volumes require long index times, no dedicated index target.
Block with robots.txt, offload crawling/indexing to dedicated front-end server.
LDAP operations (such as authentication and user operations) causing usage spikes
Low bandwidth, remote domain controller, large profile imports.
Increase bandwidth, use Kerberos, optimize profile importing.
Backup taking too long
Using STSADM, other SQL conditions such as blocking.
Use Microsoft Data Protection Manager (DPM) or SQL 2008 with compression.
IIS out of memory conditions
Application pool and worker process recycling, improper object handling, not enough RAM, poor load balancing architecture.
Use IIS overlapped recycling, use 64-bit hardware.

Additional Resources

No comments:

Post a Comment