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
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
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
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
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
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
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
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