SharePoint Top Performance Killers & Best Practices Ivan Sanders

SharePoint ArchitectDimension Solutions inc.

ivan@dimension-si.com

Agenda Top Performance Killers Best Practices

Speed as perceived by the end user is driven by multiple factors, including how fast results are returned and how long it takes a browser to display the content

Search Search uses SQL in a very I/O intensive fashion. It is sensitive to I/O latencies on

the TempDB and the Query and Crawl file groups. One of the more difficult and time consuming jobs for a Search Administrator is to schedule the Crawls so they are not over lapping while keeping Search results fresh

Indexing/Crawling Crawling and indexing a large volume of information, documents, and Web pages

requires a large amount of computer processing. The crawl process also consumes network and other resources. The SharePoint environment must be configured properly and monitored, to ensure that the crawling and indexing process does not adversely affect the service available to users. For example, content is usually crawled and indexed during off-peak hours when servers are underused in order to maintain peak-hour services for users.

Top SharePoint Performance Killers

Top SharePoint Performance Killers Profile Import

Profile imports are used with NGES to sync your AD user details to provide access to your feed subscriptions and with SharePoint to sync your AD user details with your SharePoint User Profile

Large List Operations Having large lists by itself is not necessarily a performance issue. When

SharePoint Server renders the many items in those lists, that can cause spikes in render times and database blocking. One way to mitigate large lists is to use subfolders and create a hierarchical structure where each folder or subfolder has no more than 3,000 items. Identify large lists and work with the owners of the sites and lists to archive items or pursue other mitigation strategies

Heavy User Operation List Import/Write Another scenario of users having power they don’t realize they have.  Importing

large lists using excel or synchronizing an access db. In SQL there’s little difference between these types of user operations. 

Backup (SQL & Tape) Serious CPU and write disk I/O performance hit. SQL Litespeed or SQL 2008

backup with compression all help to lessen the performance hit.

Database Best Practices Optimize TempDb, Content, & SSP Dbs

Creating secondary files for each db Move transaction logs to a separate unique Volumes Move data in primary file so that all files arte the same size

Fragmentation occurs quickly with Dbs and Indexes that are constantly updated or in use. There are 2

types of Fragmentation that will cause SQL to slow down: ○ File System ○ Db Index/Statistics

Monitoring Weekly reports to confirm trending on wait & performance stats

DB Fill factor When an index is created or rebuilt, the fill factor value determines the percentage of

space on each leaf level page to be filled with data, therefore reserving a percentage of free space for future growth. Based on past performance and index expansion rates, Microsoft has found the fill factor should be 70 percent on all content databases.

Storage Allocate adequate storage for versioning and the recycle bin, and Defrag SQL will

perform poorly. When designing the environment, CA should consider business needs, such as versioning, and ensure that adequate disk space and I/O are available to accommodate them and leave space to perform defragmentation

VM Best Practices Web Front End (WFE) servers can be

virtualized Query Server(s) can be virtualized Index Server should DEFINITELY NOT be

virtualized SQL Server should NOT be virtualized Allocate RAW LUNs for the high performance

volumes In the absence of RAW storage volumes, you

should pre-allocate the storage space

SharePoint Best Practices Tune the content of all crawls

NGES, Coveo, SharePoint, and DocAve all crawl content. Tune the applications to reduce overlap.

This is one of the most time consuming jobs of a SharePoint administrator Use Dedicated WFE for crawling

Remove the Central Administration server from NLB rotation since it is also indexing Optimize web Design

Limit the Page Load size Maximize performance on Webparts displaying data Cleanup HTTP response codes of 300 and up (* excluding 304 & 401) Minimize HTTP Requests

Plan and Enforce Site & Content Sizes Monitor Content and perform Cleanup

Recycle App Pools For each WebSite on Each WFE at different times

Periodically run Best Practice Analyzer BPA, Trends should be transparent

Network Best Practices

Load Balancing: Implement Caching to minimize traffic to database and application services.

Secure Sockets Layer: Use hardware enabled services instead of software services.

Implement WAN Acceleration anytime you are geographically dispersed across continents or where network latency must be mitigated.

Dedicated Network Interface Cards: NIC to SQL, Dedicated NIC to Load Balancer. Avoid Shared IO.

All other things being equal, more usage, as measured by number of page views & searches reflects more satisfied users.

Q & A

Most Common WaitsParallelism

CXPACKET

Direct result of inefficient parallel processing Occurs when 1 or more threads are waiting on

another thread to finish before they can proceed Hyper-Threading can add to the problem Consider adjusting MAXDOP (at Server or Query

Level)

Most Common WaitsLocking

LCK_M_xx LCK_M_SCH_xx

Results from Locking & Blocking Long running transactions Improper or lack of indexes Poorly configured or underpowered hardware

Most Common WaitsNetwork

ASYNC_NETWORKIO

Indicates that the client is not absorbing the data as fast as SQL Server can send it

This may be related to problems with the Network itself

But more likely it is the client that is to blame

Most Common WaitsI/O

PAGEIOLATCH_xx IO_COMPLETION WRITELOG

Indicates slowness reading or writing data to physical disk

These are definite signs that you have a problem with your storage subsystem or drivers

WRITELOG waits should be kept as low as possible

Most Common WaitsLatches PAGELATCH_xx

Not related to physical IO Can indicate contention for internal resources

other than the Buffer PoolPAGELATCH_UP typically indicates contention in

Tempdb Heaps and LOB’s can cause latching Heavy Inserts onto the same pages Page splits