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 Farm
Three 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 Optimization
SQL 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 2
Manage 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 processor
Increase number of processors
Add additional server(s)
% Processor Time - Process
(w3wp)
% Processor Time - Process
Avg. Disk Queue Length
Gradually increasing, system not
in a steady state and queue is
backing up
Increase number or speed of disks
Change array configuration to
stripe
Move some data to an alternative
server
% Idle Time Greater than 90%
Increase number of disks
Move data to an alternative disk or
server
% Free Space
Less than 30% Increase number of disks
Move data to an alternative disk or
server

Performance Counters Are Essential
Memory
Available 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 memory
Paging 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 Scripts
http://developer.yahoo.com/yslow/help/#guidelines
 Configure ETags
 Make AJAX Cacheable
 Use GET for AJAX Requests
 Reduce the Number of DOM
Elements
 No 404s
 Reduce Cookie Size
 Use Cookie-Free Domains for
Components
 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 !