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
http://technet.microsoft.com/en-us/library/cc262787.aspx
Issue
|
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