This document provides an overview of how to boost performance in SharePoint. It discusses measuring and improving infrastructure, hardware, SharePoint farm, search and authentication performance. Specific techniques covered include list view throttling, performance throttling, caching, IIS optimizations, and using the developer dashboard. Testing tools like Fiddler and the Visual Studio test suite are also recommended. The goal is to understand performance bottlenecks and optimize the farm to support the required requests per second.

1. Boost the Performance of SharePoint Today!

2. ABOUT BRIAN CULVER
 SharePoint Solutions Architect for Expert Point Solutions
 Based in Houston, TX
 Author
 SharePoint 2010 Unleashed
 Various White Papers
 Speaker and Blogger

3. SESSION AGENDA
 What is Performance?
 Infrastructure Performance
 Hardware Performance
 SharePoint Performance
 Testing Performance

4. WHAT IS POOR PERFORMANCE?
 Increased end user response time
 Reduced overall system throughput

5. INFRASTRUCTURE PERFORMANCE
 Active Directory
 Exchange
 Desktops
 Network Topology
 SharePoint Farm
 Web Front Ends
 Application Servers
 Database Servers

6. SHAREPOINT FARM PERFORMANCE
 3-4 Web Servers per DC
 8 Web Servers per SQL Server
 Bandwidth and Latency<1 ms
 Workflow Running
 Search: Indexing
 iFilters
# of servers
 Scheduling and throttling of crawling

7. SEARCH PERFORMANCE
Crawl Time: How long does the overall time the
crawl takes?
Corpus Size: How big is the corpus size?
Indexing Speed: How many documents are being
indexed per second?

8. SEARCH PERFORMANCE
 Grouping content sources by speed
 Tuning crawling
 Protocol
 Authentication
 Choosing multithreaded iFilters
 Adobe ($) vs FoxIt ($$$)
 Proper infrastructure
 Dedicated Query Apps vs Distributed Query Apps

9. SHAREPOINT FARM PERFORMANCE
 Authentication Performance
# of round trips
 Processing speed of provider
 Fastest to Slowest
 Anonymous
 Kerberos
 NTLM
 Basic
 Forms and WebSSO

10. SHAREPOINT FARM PERFORMANCE
 Which Machines cause the bottleneck?
 New 2010 Performance Counters
 Watch
 CPU
 Memory
 Disk I/O
 Network

11. SHAREPOINT FARM PERFORMANCE
 Requests per Second (RPS): How many requests you
can service? RPS is used for measuring how many pages are
delivered. It can measure how many searches are executed.
 Requests per Hour (RPH): Average user requests in an
hour.
 Page Time (TTLB): How long it takes to deliver a page
back to the client? Used in conjunction with RPS
 For example, our farm needs to deliver 100 RPS and
pages should reach the client within 5 seconds.

12. SHAREPOINT FARM PERFORMANCE
 Currency Rate: 10%
 Active Requests: 1%
 Usage profiles
 Light (20 RPH) – Readers/Visitors
 Typical (36 RPH) – Readers/Writers
(discussions/lists/etc.)
 Heavy (60 RPH) - Readers/Writers (Upload some/
MySites/publishing/libraries/etc.)
 Extreme (120 RPH) – Lite Readers/Constant
Writers (Upload/MySites/publishing/RSS/Many
Sites/etc.)

13. SHAREPOINT FARM PERFORMANCE
 How many RPS are needed for your farm?
 Actual: Use historical data
 IIS Logs, Web Trends, etc.
 Estimate: Number of Active Users
 (# users) x (# operations per usage profile)
 Factor in concurrency

14. SHAREPOINT FARM PERFORMANCE
 Example:
 100k users, 20k active, concurrency 5% to 10%
peak
 10% light, 70% typical, 15% heavy, 5% extreme
 20k x 20 x .1 = 40,000 RPH
 20k x 36 x .7 = 504,000 RPH
 20k x 60 x .15 = 180,000 RPH
 20k x 120 x .05 = 120,000 RPH
 844,000 / 3600 = 235 RPS
 235 x .1 = 23.5 RPS required

15. SHAREPOINT FARM PERFORMANCE
 What can our farm support?
 Input/Output Operations Per Second (IOPS):
Storage vendors publish IOPS for their hardware.
 Derive speed needs from RPS calculations
 Derive backup needs from content size
 1 IOP per RPS  1 IOP = 1 RPS
 Measured with tools such as Iometer (originally
developed by Intel), Iozone, FIO and Data Test
Program (dt).

16. SHAREPOINT FARM PERFORMANCE
 Example:
 100k users, 20k active, concurrency 5% to 10%
peak
 10% light, 70% typical, 15% heavy, 5% extreme
 Our farm requires 23.5 RPS (IOPS)
 Our farm supports 200 IOPS
 Success! Our farm is well above the required.
Plan for 10 IOPS per AVG hourly RPS
 Handle peak loads!
 Success! Our farm can handle peak loads.

17. SHAREPOINT FARM PERFORMANCE
 Understand SharePoint workload
 Use RAID 10 over other RAID ##
 And yes, RAID 10 for SharePoint is better than RAID 5
 Separate your database files
 ** Tempdb is the most heavily used DB **
 Place different databases on different volumes
 Log files separate from data files
 SQL Server files separate from other uses (e.g. OS files)
 Separate your files according to I/O workload.
 A single volume may be fast enough to handle several databases.

18. COMMON PERFORMANCE PROBLEMS
 Large Lists
 Lots of Web Parts importing non-cached data
from various places
 Cross-List queries and CBQ Web Parts
 Too Deep Site Structures
 Too many sites in a site collection
 Too many site collections in a Content DB
 Too many ACLs

19. SHAREPOINT PERFORMANCE
We will discuss the following:
 Large List Control
 Performance Throttling
 Developer Dashboard
 Good for IT Pros and Developers alike
 Caching
 IIS 7.0
 Content Query Web Part

20. LARGE LIST CONTROL
So what is new?
 Lists and Libraries hold 50,000,000 items
 Recommended List View Size:
 Why 2000 or 5000?
 Server Overload
 Solution: List View Throttling

21. LIST VIEW THROTTLING
 Limits the number of list items returned per
view.
 Operations that exceed this limit are prohibited.
 Recommended to configure at the Web
Application level.
 Default List View Threshold values:
 5000for Users
 20000 for Auditors and Administrator

22. LIST VIEW THROTTLING
 List can be configured individually via API
 Daily Time Window for Large Queries: Turn off
Throttling during a daily window
 Comes with a Warning
 List View Lookup Threshold: How many
complex fields are allowed
 Lookup, Person/Group, or workflow status fields
 Result in JOINs

23. PERFORMANCE THROTTLING
 HTTP Request Monitoring and Throttling:
Throttle Performance during high server load
 SharePoint monitors performance counters and
uses threshhold values
 Get 503 request errors
 Timer Job fails to start
 PUT request still allowed
 Search can trigger performance throttling and
cause issues

24. PERFORMANCE THROTTLING
 Protects the server during peak loads. Monitors:
 Available Memory
 CPU %
 ASP.NET Queue
 Wait time in queue
 Checked every 5 seconds
 3 over limit start throttling, logs events
 1 below limit stop throttling
 Configure via PowerShell and Object Model
 Adds/Remove counters via Object Model

25. DEMO
List View Throttling and Load Performance Throttling

26. LIST VIEW THROTTLING

27. LIST VIEW THROTTLING

28. LIST VIEW THROTTLING

29. LIST VIEW THROTTLING

30. LIST VIEW THROTTLING

31. CACHING
 Page Output Cache: for generated HTML markup
for future requests
 Cache frequently used Lists and reduce round trips to
the database
 Object Cache: for common objects and query
results
 Content Query Web Part
 List Views
 Disk-Based (BLOB) Cache: for commonly
requested files on WFE disks
 Automatically cache BLOBs and reduce round trips to
the content databases

32. CACHING
 Configure caching via the Site Settings
 Configure caching via web.config for Web
Applications.
 Web.config overrides the Site Settings.

33. Caching
DEMO

34. IIS 7.0 PERFORMANCE
 Design pages for fast downloading and
rendering
 Lazy loading of large JavaScript files
 Clustering images
 Reduce image requests
 Reduce the number of secured items in pages
 Each secured request results in two roundtrips
 Validate
credentials
 Enumeration of groups the user belongs to
 Leverage IIS Compression

35. IIS 7.0 PERFORMANCE
 Reduce amount of data sent to client and
reduce the number of trips a browser makes.
 View State Caching and Reduce Payload.
 Cache View State to be used in subsequent post-
backs
 Minify JavaScript
 Remove redundant white spaces and new lines
 Reduce File Requests
 Merge multiple JavaScript/CSS files in one request

36. IIS 7.0 PERFORMANCE
 Increase static and dynamic compression level to 9
Appcmd.exe set config -section:httpCompression -
[name='gzip'].staticCompressionLevel:9 -
[name='gzip'].dynamicCompressionLevel:9
 Change dynamic compression CPU utilization
threshold range from 20-75% APPCMD.EXE set config –
section:httpCompression /dynamicCompressionDisableCpuUsage:75
APPCMD.EXE set config –section:httpCompression
/dynamicCompressionEnableCpuUsage:20
 Enable caching before insertion into page output
cache
APPCMD.EXE set config –section:urlCompression
/dynamicCompressionBeforeCache:true

37. IIS Compression
DEMO

38. CONTENT QUERY WEB PART
 Powerful web part for aggregating and rolling
up information from various sources.
 Designed to leverage the object cache by
caching the query results.
 In MOSS 2007, Disabled by default
 In SP 2010, Enabled by default
 Best performance when content shares the
same permissions and doesn’t change often.

39. CUSTOM CODE
 Common cause for poor performance
 Custom inefficient features

40. PLAN FOR SOFTWARE BOUNDARIES
 Helps understand the tested performance and
capacity limits of SharePoint
Role Specifications
1 dual core Intel Xeon 2.8
Stand-alone computer gigahertz (GHz) 64-bit processor, 2
gigabytes (GB) RAM
2 dual core Intel Xeon 2.8 GHz 64-
Web server computer bit processors, 4 gigabytes (GB)
RAM
Database computer running 4 dual core Intel Xeon 2.8 GHz 64-
Microsoft SQL Server bit processors, 32GB RAM
Pentium III 1.2 GHz processor, 1
Client computers
GB RAM

41. TESTING PERFORMANCE
 SharePoint Load/Performance Testing
 population tools, performance tuning
techniques

42. DEVELOPER DASHBOARD
 Allows monitoring page loads and
performance
 Information:
 Times to render page
 Page checkout level
 DB query info
 Web part processing time
 Any critical events or alerts

43. DEVELOPER DASHBOARD

44. Developer Dashboard
DEMO

45. VISUAL STUDIO TEST SUITE
 Test throughout
your testing
lifecycle of
planning, testing
and tracking your
progress
 Use with TFS to
automate builds,
deployments and
testing

46. FIDDLER
 Great, light weight tool. Provides quick overview
of the website performance.
 Free
 It can also records scripts that you can use in
VSTS.
 neXpert: Fiddler Add-on that checks for classic
performance best practices and produces a
HTML report on the issues found in a Fiddler
capture.

47. YSLOW
 Analyzes web pages and
suggests ways to improve their
performance based on a set of
rules for high performance
web pages.
 Grades web page based
rulesets.
 Suggests performance
improvements, summarizes
page components, statistics
for the page, and provides
tools for performance analysis.

48. QUESTIONS

49. BRIAN CULVER, MCM
TWITTER:
@SPBRIANCULVER
E-MAIL:
BRIAN.CULVER@EXPERTPOINTSOLUTIONS.COM
BLOG:
SPBRIAN.BLOGSPOT.COM