SharePoint Saturday The Conference 2011 - SP2010 Performance

Boost the Performance of SharePoint Today!

Welcome to SharePoint Saturday—The Conference Thank you for being a part of the first SharePoint Saturday conference • Please turn off all electronic devices or set them to vibrate. • If you must take a phone call, please do so in the hall so as not to disturb others. • Open wireless access is available at SSID: SPSTC2011 • Feel free to “tweet and blog” during the session • Thanks to our Diamond and Platinum Sponsors:

About Brian Culver– SharePoint Solutions Architect for Expert Point Solutions– Based in Houston, TX– Author • SharePoint 2010 Unleashed • Various White Papers– Speaker and Blogger

Session Agenda• What is Performance?• Infrastructure Performance• Hardware Performance• SharePoint Performance• Testing Performance

What is Poor Performance?• Increased end user response time• Reduced overall system throughput

Infrastructure Performance• Active Directory• Exchange• Desktops• Network Topology• SharePoint Farm – Web Front Ends – Application Servers – Database Servers

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

Search PerformanceCrawl Time: How long does the overall time the crawltakes?Corpus Size: How big is the corpus size?Indexing Speed: How many documents are beingindexed per second?

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

SharePoint Farm Performance• Authentication Performance – # of round trips – Processing speed of provider• Fastest to Slowest – Anonymous – Kerberos – NTLM – Basic – Forms and WebSSO

SharePoint Farm Performance• Which Machines cause the bottleneck?• New 2010 Performance Counters• Watch – CPU – Memory – Disk I/O – Network

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.

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

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

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

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

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.

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.

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

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

Large List ControlSo 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

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: – 5000 for Users – 20000 for Auditors and Administrator

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

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

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

DEMOList View Throttling and Load Performance Throttling

List View Throttling

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 – Tune using “Cache API Hit Ratio”; aim for 90%• Disk-Based (BLOB) Cache: for commonly requested files on WFE disks – Automatically cache BLOBs and reduce round trips to the content databases

Caching• Configure caching via the Site Settings• Configure caching via web.config for Web Applications. – Web.config overrides the Site Settings.

DEMOCaching

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

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

IIS 7.0 Performance• Increase static compression level to 9 and dynamic to 5 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

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.

But performance still sucks• Look at everything• Performance is based on the entire farm, including content• Lets share some stories!

But performance still sucks• Less than 500 “actual” users• Web Application is going to sleep• Default idle timeout is 20 minutes• Does 0 for infinite actually work?

Custom Code• Common cause for poor performance• Custom inefficient features

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

Testing Performance• SharePoint Load/Performance Testing• population tools, performance tuning techniques

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

Developer Dashboard Always ON for all users ON stsadm -o setproperty -pn developer-dashboard -pv on Completely OFF for all users OFF stsadm -o setproperty -pn developer-dashboard -pv off Available to Site Administrators (Toggle on top-right)On-Demand stsadm -o setproperty -pn developer-dashboard -pv ondemand

DEMODeveloper Dashboard

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

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.

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

Welcome to SharePoint Saturday—The Conference Thanks to our SponsorsThanks to Our Other Sponsors!

Questions

Brian Culver, MCMTwitter:@spbrianculverE-mail:brian.culver@expertpointsolutions.comBlog:spbrian.blogspot.com

Welcome to SharePoint Saturday—The Conference Session Evaluation Please complete and turn in your Session Evaluation Form so we can improve future events. Survey can be filled out at: http://app.fluidsurveys.com/surveys/spstc2011- and add the Session number to the URL Presenter: Brian Culver Session Name: Boost the Performance of SharePoint Today! Session No.: Fri-S3A-102

http://blog.expertpointsolutions.com	437
http://paper.li	12
http://spbrianculver.wordpress.com	5
http://twitter.com	1
http://www.expertpointsolutions.com	1
http://translate.googleusercontent.com	1

SharePoint Saturday The Conference 2011 - SP2010 Performance

by Brian Culver

Accessibility

Categories

Upload Details

Usage Rights

6 Embeds 457

Statistics

SharePoint Saturday The Conference 2011 - SP2010 Performance Presentation Transcript