Souping Up Your SharePoint Farm

Nigel Price - NJPEnterprises

Introduction• Nothing Here cannot be found elsewhere• This not an exhaustive list – I am sure I have forgotten some things

The Font of All Knowledge (Performance Wise)• Microsoft’s Software boundaries and limits for SharePoint 2013

• (http://technet.microsoft.com/en-us/library/cc262787.aspx)

• A reminder of the Microsoft definitions:• Boundary = static limit that cannot be exceeded by design• Threshold = configurable limits that can be exceeded to accommodate

specific requirements• Supported = configurable limits that have been set by default to a tested

value.

Architecting the FarmThree Layers of SharePoint Infrastructure

Web

Service Apps

Data

Architecting the Farm

• 2 Dedicated Web Servers (NLB)

• 2 Service Application Servers

• 2 Database Servers (Clustered or Mirrored)

• 1 or 2 Index Partitions with equivalent query components

Best Practice ‘Six Server Farm’

Networking• Separate user and database traffic

• connectivity between front-end servers and SQL should be isolated, either via separate physical networks or virtual LANs.

• requires at least two separate network interface cards in each front-end Web server with static routes configured to ensure traffic is routed to the correct interface.

SQL Server Tuning• Set Maximum Amount of SQL Server RAM to 90% of available RAM• When Formatting the SQL Data / Logs Disks Use Fill Factor of 80 and

format blocks to 64K (Not the default of 4K)• Set MAXDOP to 1• Set the Recovery Model to Simple on the Model Database. (Some

SharePoint Databases do not use this) – Unless you are Using HA or similar

• Provision the major SharePoint databases on separate physical disks (or LUNs if a storage-area network is involved)

SQL Server Optimization

• Break Content Databases and TempDB into multiple files (MDF, NDF), total should equal number of physical processors (not cores) on SQL server.

• Pre-size Content DBs and TempDB to avoid fragmentation• Separate files onto different drive spindles for best IO perf.• Example: 50GB total Content DB on Two-way SQL Server would have two

database files distributed across two sets of drive spindles = 25GB pre-sized for each file.

Multiple Files for SharePoint Databases

SQL Database OptimizationSQL Maintenance Plans

• Implement SQL Maintenance Plans!• Include DBCC (Check Consistency) and either Reorganize Indexes or

Rebuild Indexes, but not both!• Add backups into the

maintenance plan if they don’t exist already

• Be sure to truncate transaction logs with a T-SQL Script (after full backups have run…)

Search• Do not run Incremental crawls whilst running Full Crawls

• They do not play nicely – Full crawl can go from hours to days if you do this• Switch off continuous crawls as well.

• If possible have separate server dedicated to search so that crawler crawls this rather than web servers thus preventing user requests for pages and crawler requests for pages clashing.

Web Applications and Site Collections• Use Host Named Web Applications (you only ever need one)• Use Host Named Site Collections• Can only be done using PowerShell• Infinitely more scalable than path named Site Collections• Based on Microsoft evidence / experience of Office 365

Minimise Page Size• For users on the far end of a slow WAN link the heavyweight nature of

a typical SharePoint page can be a real performance-killer.• Start with a minimal master page and add to it. Remember each page

has a master page behind it !• Most SharePoint pages contain links to supporting files.

• Make sure these files are only loaded when they needed (SharePoint’s Load on Demand)

• Make use of SharePoint’s loading files in the background (they load whilst the page is rendering)

Minimising Page Size Part 2Manage page customisations

• SharePoint Designer can be harmful to overall performance !• Allows certain types of users to modify what goes into a page• When Page Layouts / Pages are modified they go into the content database so

every time they are required we have a round trip to the Content Database.

• Watch those Images – they may look nice but they may be large• If possible load css first, HTML next and then javascript to speed up

rendering• Download an image which contains lots of images and use css to pick

out the one you want. (Image slicing)

Take advantage of caching• SharePoint 2013 comes with Distributed Caching – make sure its

working (Want to know more – Get Spence Harbar’s video on it)• Need at least CU4

• Various Types of Caching• Blob Caching• Page Caching• Object Caching

• Make sure you make use of them !• Cache profiles can also be configured by page type, so publishing

pages and layout pages behave differently

Limit Navigation Depth• Watch out for the global, drop-down, fly-out menu at the top of each

page.• Fetching all the data to populate these navigation menus can be

resource-intensive on sites with deep hierarchies.• The Navigation Depth should be limited to a manageable level that

does not impact performance.

Performance Counters Are Essential% Processor Time (_Total)

Over 75-85%Upgrade processorIncrease number of processorsAdd additional server(s)

% Processor Time - Process (w3wp)

% Processor Time - Process

Avg. Disk Queue LengthGradually increasing, system not in a steady state and queue is backing up

Increase number or speed of disksChange array configuration to stripeMove some data to an alternative server

% Idle Time Greater than 90%Increase number of disksMove data to an alternative disk or server

% Free SpaceLess than 30% Increase number of disks

Move data to an alternative disk or server

Performance Counters Are EssentialMemoryAvailable Mbytes Less than 2GB on a

Web server. Add memory.

Cache Faults/sec Greater than 1

Increase cache speed or size if possible

Move data to an alternative disk or server

SQL server available memory will be low, by design, and does not always indicate a problem.

Memory Pages/sec Greater than 10 Add memoryPaging File

% Used and % Used Peak

The server paging file, sometimes called the swap file, holds "virtual" memory addresses on disk. Page faults occur when a process has to stop and wait while required "virtual" resources are retrieved from disk into memory. These will be more frequent if the physical memory is inadequate.

Add memory

Javascript• Reduce what comes back after a REST call

• Accept : "application/json;odata=verbose“ – worst• Accept : "application/json;odata=minimalmetadata" (OR

Accept : "application/json") – better• Accept : "application/json;odata=nometadata“ - best

Tools• Use the Built in Tools to find bottlenecks

• Eg Google Chrome Network Settings -> Tools -> Developer Tools -> Network

• WebTestPage.org (Internet Sites only)• Use Fiddler to look at :-

• Size of pages• Page Headers

• Farm Health (0 is good and 10 is bad)

• Use WireShark to inspect packets• Use Developer Dashboard to see where the bottleneck is

Mobile• Keep essential information on one page • Display multiple List View Web Parts in a single page view • Display recent changes to the site • Create separate SharePoint sites for different groups of users or

products• Make sure content is accessible at all times – even on a poor

connection• Get the biggest cache possible

The Way We Were• Traditional “performance optimisation”

• Web Server Tuning• Application Server Tuning• Database Query Tuning• Code re-factoring

• The focus was INSIDE the data centre…• Trying to optimise something that normally takes less that 200ms

(“data start time”)

But…….

•80% of the page load time is spent outside the data centre!!!

Steve Souders “High-Performance Websites”

So…..

• Focus on the “front end”• Optimise the interaction between the browser and the data-centre• And how the browser processes the client-side objects

The Building Blocks of Web Performance

TCP/IP

HTTP

Browser

HTML CSS Javascript IMG

Yahoo’s Rules - ySlow• Minimize HTTP Requests• Use a Content Delivery Network• Add an Expires or a Cache-Control Header• Gzip Components• Put StyleSheets at the Top• Put Scripts at the Bottom• Avoid CSS Expressions• Make JavaScript and CSS External• Reduce DNS Lookups• Minify JavaScript and CSS• Avoid Redirects• Remove Duplicate Scriptshttp://developer.yahoo.com/yslow/help/#guidelines

Configure ETags Make AJAX Cacheable Use GET for AJAX Requests Reduce the Number of DOM Element

s No 404s Reduce Cookie Size Use Cookie-Free Domains for Compo

nents Avoid Filters Do Not Scale Images in HTML Make favicon.ico Small & Cacheable

Google’s Rules - PageSpeed• Avoid bad requests• Avoid CSS expressions• Combine external CSS• Combine external JavaScript• Defer loading of JavaScript• Enable compression• Leverage browser caching• Leverage proxy caching• Minify CSS• Minify HTML• Minify JavaScript• Minimize request size• Minimize DNS lookups• Minimize redirects

http://code.google.com/speed/page-speed/docs/rules_intro.html

• Minimize redirects• Optimize images• Optimize the order of styles and scripts• Parallelize downloads across hostnames• Put CSS in the document head• Remove unused CSS• Serve resources from a consistent URL• Serve scaled images• Serve static content from a cookieless domain• Specify a character set early• Specify image dimensions• Use efficient CSS selectors

But There Are 5 Important Ones• Reduce Page Size (<500Kb)• Enable (Gzip) Compression• Reduce the number of roundtrips (<40 per page…)• Structure the page (to improve render & download)

• CSS First• Javascript last

• Cache, Cache, Cache

Low hanging fruit…

•Even if you apply just those 5 rules…Your page download times will drop by ~50%

Summary• Look at each layer of your SharePoint farm• Tune SQL Server, in terms of formatting disks• Have multiple files for content databases and tempdb• Cache everything you can on your farm• Pay attention to your performance counters and act on them• Look at your network bandwidth and latency• Pay attention to your loading order CSS, HTML, Javascript• Watch the size of the size of those images ! And keep the size of your pages to a minimum• Cache as much as you can in the client• Reduce the number of round-trip to the server by the client

Any Questions ?

Thank You !