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 http://technet.microsoft.com/en-us/library/cc262787.aspx
High disk I/O
activity on SQL Server
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
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
enabled. Caching not enabled or not configured. Large pages. Redundant SQL
trips, underlying network issues.
and compression, check page load times, and examine SQL queries and round
trips, check NIC for Broadcom 5708 Chimney issues.
Long time to load
SharePoint object handling in custom code, slow links, SQL blocking, timer
jobs, Web part caching not enabled.
bandwidth and response issues, dispose of objects properly, use 64-bit
hardware or configure memory pool limits, delay downloading core.js.
>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
volumes require long index times, no dedicated index target.
robots.txt, offload crawling/indexing to dedicated front-end server.
(such as authentication and user operations) causing usage spikes
remote domain controller, large profile imports.
use Kerberos, optimize profile importing.
Backup taking too
other SQL conditions such as blocking.
Data Protection Manager (DPM) or SQL 2008 with compression.
IIS out of memory
and worker process recycling, improper object handling, not enough RAM, poor
load balancing architecture.
overlapped recycling, use 64-bit hardware.