sharepoint 2010 boost your farm performance!

Boost the Performance of SharePoint Today!

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

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


Authentication Performance

# of round trips

Processing speed of provider

Fastest to Slowest

Anonymous

Kerberos

NTLM

Basic

Forms and WebSSO


Which Machines cause the bottleneck?

New 2010 Performance Counters

Watch

CPU

Memory

Disk I/O

Network


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.


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


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


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


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


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.


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

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

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

DEMO

List View Throttling and Load Performance 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

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.

DEMO

Caching

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

DEMO

IIS Compression

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.

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

Stand-alone computer

1 dual core Intel Xeon 2.8

gigahertz (GHz) 64-bit processor, 2

gigabytes (GB) RAM

Web server computer

2 dual core Intel Xeon 2.8 GHz 64-

bit processors, 4 gigabytes (GB)

RAM

Database computer running

Microsoft SQL Server

4 dual core Intel Xeon 2.8 GHz 64-

bit processors, 32GB RAM

Client computers Pentium III 1.2 GHz processor, 1

GB 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

DEMO

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

QUESTIONS

BRIAN CULVER, MCM

TWITTER:

@SPBRIANCULVER

E-MAIL:

[email protected]

BLOG:

SPBRIAN.BLOGSPOT.COM

sharepoint 2010 boost your farm performance!

Documents