This document provides an overview of SharePoint 2010 performance and capacity planning best practices. It discusses infrastructure considerations like network configuration, server design based on workload, and database sizing calculations. It also covers configuration techniques such as caching, compression, throttling and monitoring. Specific areas covered in more detail include pages, customizations, branding, and large lists. The presentation includes demonstrations of tools like the developer dashboard for performance troubleshooting.

1. SharePoint 2010
Performance and Capacity
Planning Best Practices
Eric Shupps
SharePoint Server MVP

2. About Me
• SharePoint Server MVP
• President, BinaryWave
• Microsoft Patterns & Practices (spg.codeplex.com)
• CKS:DEV (cksdev.codeplex.com)
• Web: www.binarywave.com
• Blog: www.sharepointcowboy.com
• Twitter: @eshupps
• Facebook: www.facebook.com/sharepointcowboy

3. Agenda
• Infrastructure
– Network
– Servers
– Databases
Demonstrations
• Configuration
– Caching
– Compression 10
– Throttling and Locks 8
• Pages 6
– Customization 4
– Branding 2
Load Time
– Lists
• Instrumentation

4. Infrastructure

5. Network
• Capacity
• Load
• Traffic Isolation
– Web
– Database
– Service
Applications
– Search
– Authentication
• Indexing

6. Servers
• Design to function
– Heavy read operations require
more web servers
– Heavy write operations require
increased SQL IOPS
– Heavy services (i.e. Search)
require additional application
servers
• Design to Locality
– Global distribution with heavy
write may require localized farms

7. Database Operations
Search
Security Trimming
Workflow
Content Query
Intensity
Publishing
Collaboration
Social
Client Access Browsing
Frequency

8. Database Calculations
Variable Value Total Database Sizing
# Documents 1,000,000 Estimate
Average Size 150 KB 864.4 GB
# List Items 3,000,000
# Versions 3
Formula: Database size = ((D × V) × S) + (10 KB × (L + (V × D)))
Database Size Estimates Number of User Profiles
Content DB Size 486.5 GB 50,000
Crawl 22.4 GB
Property 7.3 GB
Profile 48.8 GB
Sync 30 GB
All other DB’s 269.5 GB

9. Application Databases
• Small to moderate size
• Moderate transactional volume Profile
• Group on moderate
PerformancePoint
cost/performance disk
• Analytics BCS
– May be quite large PowerPivot
– May require isolation App Registry
– Reporting increases
operational overhead
Word Automation Analytics

10. Content Databases
• Practical limit is 200GB
– Max supported limit is 4TB*
• Create separate databases for:
– Site collections with large lists
– Large numbers of subsites
– Intensive read/write operations
– Data isolation (security)
• Consider amount of time it takes Content
to backup/restore

11. Search Databases
• Crawl databases can be
extremely large
• High index sensitivity
Admin Properties
• Heavy transactional volume
• Isolate crawl and temp
databases
– Distribute across spindles
and LUN’s Crawl
• Highest performance disk

12. Database Management
• Manually configure auto-growth
settings
• Defragment indexes on a regular
basis
• Limit content DB size per site
collection
• Assign disks based on size, volume
and sensitivity
• Isolate transaction logs
• Implement regular backup schedule
to reduce log file size
• Enforce quotas

13. Configuration

14. SharePoint Caching
Page Disk Object
First request served
Commonly
from content File-system objects
requested objects
database, output cached by IIS
stored in memory
written to memory
Subsequent
requests for same Database objects Cross-site queries
resource read from not cached cached in memory
memory

15. DEMO
Managing Cache Settings

16. IIS Compression
• Reduces size of files transmitted
across the wire
• Caches compressed content on
disk
• Configurable for various file types
• Compression range from 0 - 9
• Increases CPU utilization on WFE’s
– Size hardware accordingly
• Does not effect dynamic content
retrieved from database

17. DEMO
Setting Compression Levels

18. Throttling and Locks
• SQL Server escalates row locks to table
locks
(> 5000)
• Query throttling reduces the impact of
any single request by limiting the amount
of data queried
• Throttling is configurable and can be
altered for administrators and specific
time periods
• Bit rate throttling controls download
speeds of large objects (video, Flash,
Silverlight)
– Dependent upon BLOB cache

19. DEMO
Resource Throttling

20. Pages

21. Page Controls
• Navigation
• Menus
• Ribbon
• Delegate
• Security Trimming
• Publishing Fields
• Search
• Layout
• Hidden

22. Page Data Queries
Page
Master Layout Navigation Menu Web
Permissions
Page Page Controls Options Parts
File
Database External
System
Data Sources

23. Page Customizations
Uncustomized Customized
Cache

24. Test Results
Average Performance Delta: ~10%
0.1
0.08
0.06
0.04
0.02
0
1 2 3 4 5 6 7 8 9 10
Uncustomized Customized

25. DEMO
Customization

26. Branding
• Start with a minimal master page
• Minify and consolidate linked files
– Reduce size and number of GET operations
• Use image stitching (CSS sprites) on pages
with a lot of small images to reduce
number of requests
• Store resources (style sheets, master
pages, layout pages, images) on the
PHYSICAL file system (i.e. /_layouts/) not
the VIRTUAL file system (Style Library,
Publishing Images)
– Assets in libraries are stored in database
– Easy for users to modify but reduce
performance

27. Lists

28. List Items
• Just because a list CAN hold millions
of items doesn’t mean it SHOULD
• All user content in all lists
throughout entire site collection is
stored in a single table in the
content database
– Consider query impact across site
collection
• Folders improve view performance
NOT query performance
• List view web parts are now XSLT
based; however, large list displays
may still require custom code

29. List Definitions
• Rows
– More than 5,000 rows in a list is “large”
• Default throttle limit
• Corresponds to SQL lock escalation
triggers
• Monitor locks if increasing throttle limit
• Columns
– More columns = more SQL rows
– More SQL rows can slow down performance
up to 35%
• Storage
– Use Remote Blob Storage to eliminate storage
of large files within SQL
– Not intended to increase query performance

30. Instrumentation

31. Developer Dashboard
• Developer Dashboard provides
metrics on object execution for
individual pages
• Displays code-level request data for
events
• Provides drill-down process isolation
• Specifies related database queries
• Identifies request allocations and
control event offsets
• Developers can implement
monitoring scopes to display
component performance data

32. Dashboard Example
Total Page Execution
Time
Related
Queries
Control Events

33. DEMO
Using the Developer
Dashboard to Isolate
Performance Issues

34. More Information
SharePoint Server 2010 Capacity Management: Software http://technet.microsoft.com/en-
Boundaries and Limits us/library/cc262787.aspx
Capacity Management and Sizing Overview for SharePoint http://technet.microsoft.com/en-
Server 2010 us/library/ff758647.aspx
Capacity Planning for SharePoint Server 2010 http://technet.microsoft.com/en-
us/library/ff758645.aspx
Performance Testing for SharePoint Server 2010 http://technet.microsoft.com/en-
us/library/ff758659.aspx
Storage and SQL Server Capacity Planning and http://technet.microsoft.com/en-
Configuration us/library/cc298801.aspx
Performance and Capacity Technical Case Studies http://technet.microsoft.com/en-
us/library/cc261716.aspx
Monitoring and Maintaining SharePoint Server 2010 http://technet.microsoft.com/en-
us/library/ff758658.aspx
Performance Testing for SharePoint Server 2010 http://technet.microsoft.com/en-
us/library/ff758659.aspx

35. Thank You for attending this session!
Please fill in the evaluation form