SPC311: Best Practices for Building your Website for Scale with ...

adhocjackpotΑσφάλεια

5 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

91 εμφανίσεις



Capacity
Planning

Architect
for Scale

Pilot &
Test

Deploy

Monitor &
Validate


PLEASE look at the test
results/guidance we published
on SharePoint
2010 as a baseline.



Take
-
away:


A well
-
architected site on circa 2010 hardware can handle THOUSANDS of
requests per second (RPS) (== 172 million requests per day)


http
://technet.microsoft.com/en
-
us/library/gg398060.aspx



Caching:
How do I cache as much as possible?


Incl. a quick note on CDNs



IIS
Compression:
Where can I turn it on?



Content Deployment:
Should I use it? How?



Variations:
How should I use it?



What?

Where?

ASP.Net

Page Output
Cache

Compiled
ASP.Net

Pages

In RAM on the Web
Front
-
End server

SharePoint Object
Cache

Result set for
SharePoint queries

In RAM on the Web
Front
-
End server

Disk
-
based cache for
Binary Large Objects
(BLOB cache)

Static files (images,
videos, sound, CSS,
JavaScript, etc.)

On
-
disk on the Web
Front
-
End servers



Questions to ask yourself / your project sponsors:


How often is content on your site updated?


How bad is waiting 1 minute for content to appear, really?



Some approximate math:


1


(# of requests per second / # of seconds of caching) = % of work saved


E.g. If you cache for 60 seconds, and you get 1 request per second, you save the server
98.3% of potential rendering work.



Setting user expectations:


Content Authors will need to understand that the page they just published
won’t show up on a Content Query for <# of seconds of caching>. They will
otherwise think it’s a bug.


Configuration:

1.
Create/edit your Cache Profiles:


Site Settings


Site Collection
Administration


Site Collection
Cache Profiles

2.
Enable Output Caching & Assign
Cache Profiles:


Site Settings


Site Collection
Administration


Site Collection
Output Cache





Key Configuration Decisions (all part of cache profiles):



Parameter Name

Decision

General

Principle

Duration

How many seconds should these pages

be
cached?

Trade
-
off freshness vs. work saved

Check

for Changes

Do I want a purely time
-
based

cache, or should
every request check to see if cache is still valid?

Avoid unless ABSOLUTELY
necessary

Vary by
HTTP Header
/ Query String
Parameters / User
Rights / Custom

Do I want SharePoint

to cache a separate
version of the page per <query string/HTTP
Header/etc.>

The more things you vary

by, the
more requests are un
-
cached.


Sometimes you want completely “dynamic” content elements on
an
otherwise cached page.


You can achieve exactly this behavior, by writing a custom control that
inherits
from the

class.


The rest of the page will be output
-
cached, but this control will be called to
render on every request.



Key consideration:
Your control will be run on EVERY request… plan
carefully.



What is the Object Cache?


An in
-
memory cache of results to “Cross
-
List Queries” against your
SharePoint site.


Used to cache the results of queries that can span lists and sites within a Site
Collection.


But also good for caching results of queries within a single list.



Am I already using it on my site?


Yes… because it’s used by the Content Query Web Part and by the Navigation
Control.

Site Settings




Site Collection
Administration




Site Collection
Object Cache


Key Configuration Decisions

Parameter Name

Decision

General

Principle

Object Cache Size

How big do

you want the Object Cache to be?

Bigger is better (make sure you
have enough RAM)

Cache Changes

Do I want a purely time
-
based

cache, or should
every request check to see if cache is still valid?

Checking for changes == more
work

per cached request

Results Multiplier

Should we cache more results than the

user
asked for?

Only useful in scenarios where
different

users have different
permissions…


Configure the two “super” accounts used by the Object Cache via
PowerShell:





Account Name

Permissions

it should have

SuperUser

Full Control User Policy for the Web Application

SuperReader

Full Read User Policy for the Web

Application



What went wrong?


The hero control (which was implemented as a
Sandboxed Solution) was using the non
-
cached
SharePoint API, instead of the cached API.


The site was launched, and as soon as it got real
load, the Sandboxed Solution throttling system
(correctly) stopped executing the control.

Good

Bad


To build a client
-
side solution (Silverlight/AJAX/Flash/etc.) that queries
SharePoint data:

1.
Write a web service that wraps the Object Cache and executes cache queries

2.
Make sure your solution calls your web service.


Do NOT use the SharePoint client object model… it is un
-
cached.


What is it?


A cache that stores files on the web
-
front end’s disk drive.



Why should you use it?

1.
Less rendering work for SharePoint:
Serving a file from the BLOB cache is
way more efficient than serving it from the Content Database.

2.
Less bytes
-
over
-
the
-
wire for users visiting your site:
Files served from the
BLOB cache will pass an HTTP header telling browsers NOT to cache the
pages locally for the specified time period.

3.
Support for HTTP range requests for media files like audio & video:
Files
served from the BLOB cache support HTTP range requests, which are used
by media players for seeking/progressive downloading.


Edit the following line in
web.config
:

Parameter
Name

Decision

General

Principle

Location

Where do you want the BLOB cache to store

its files

Put it on its own drive. (Don’t

share
with Logs, System Drive, etc.)

Path

What file extensions

do you want to cache?

More is better

MaxSize

How much disk space (GB) should the BLOB cache use?

More is better

Max
-
age

For

how many seconds should clients cache these files?


Longer is better, but

too long &
clients won’t see updates.


If off
-
loading file serving requests from SharePoint’s Content
Database is good, then moving them off of your SharePoint farm
entirely can be better.


Less load on your server per
-
user


Browsers will load more files in parallel (due to 2 connection per
-
server limit)



… But there’s no such thing as a free lunch:


Files stored in the CDN are just “external URLs” to SharePoint. No scheduling,
permissions, etc.



As
part of your architecture, consider what content you might want
to load from CDNs.


Good candidates are files that don’t change often/ever, and that aren’t
permission sensitive.



If the files will ever change, make sure you plan the update process.



Easy win:
If you’re using
jQuery

or
Modernizr
, load them from
the
ASP.Net

AJAX CDN
.



Because less bytes
-
over
-
the
-
wire == a
“faster” site



We STRONGLY
recommend
enabling static &
dynamic
compression.

Content Deployment is great for customers who:

1.
Have
a business/regulatory/legal requirement that no user can have
contributor permissions on their production site
.

2.
Will be reviewing/staging ALL content before it goes live.


Content Deployment adds LATENCY between when Content is
authored/approved & when it goes live.


Latency is proportional to the volume of changes since last deployment.


And if you have multiple targets, things will be temporarily out of sync.


We see lots of customers using Content Deployment without actually
having the need to.


If you’re running Content Deployment on an automated schedule of “every
15 minutes”… what value are you getting?



We’re seeing many customers moving to “author
-
in
-
place” (using
Scheduling/Approval for content staging) with great success.



Content Deployment

+
SQL
Server 2008
Enterprise

= No export failures due to on
-
going authoring activity.


How it works:


SharePoint takes
Content DB snapshot
before export starts


SharePoint exports from
snapshot


User edits go to “live” Content DB


SharePoint deletes
Content DB snapshot
after export completes



Central Administration




Manage Content
Deployment Paths and Jobs




<Your Job>


Custom Solutions MUST be “aware” of Content Deployment


Many custom solutions add/modify Content DB objects (and fail if they
can’t add/modify the objects).


The pattern we see in many custom solutions:

1.
Admin activates solution on SOURCE of Content Deployment

1.
Objects are added to the Content DB

2.
Content Deployment will then do the following on the TARGET:

1.
Deploy the content objects to the target Content DB

2.
Automatically activate the custom solution (FAIL)


How to write Content Deployment
-
friendly code:



1.
Avoid “Multilingual Afterthought Syndrome”


If you think you may need Variations in the future, set up Variations early
on.


If you do this later, you’ll have to copy a LOT of content from the root web to
your source label.



2.
Consider On
-
Demand Page Propagation:


It can save a LOT of unnecessary copy operations.


Normal
Propagation:



Every time a page is added/updated, it’s copied to
target labels.


Target label
owners
have to
delete any versions they don’t
want. (E.g. spelling errors, source
-
only changes, etc.)



On
-
Demand Propagation:


Source author decides whether to copy any pages out to target
labels.



Lots of guidance on TechNet:
Performance Testing for SharePoint
Server 2010


Key Resource:
SharePoint Server 2010 Load
-
Testing Kit for Visual Studio Team
Services.



Lots of guidance @
Monitoring & Maintaining SP2010 on TechNet


ethang@microsoft.com