Session about how to optimize public-facing sites built on SharePoint publishing infrastructure. Session is based on real-life experiences and provides valuable information to all SharePoint developers who build sites using SharePoint publishing infrastructure. It was special session for SPUG.fi community meeting.

1. Optimizing public
facing SharePoint sites
Gunnar Peipman
IIS/ASP.NET MVP
http://weblogs.asp.net/gunnarpeipman/
me@gunnarpeipman.com

2. About me
 Name: Gunnar Peipman
 From: Tallinn, Estonia
 MVP: ASP.NET MVP for 4
years
 Job: developer, architect
and consultant
 Community: ENETA,
speaker, blogger
 Hobbies: new technology,
heavy metal, beers,
national cuisines, travelling
 Happy boyfriend, father,
step father and owner of
funny white rabbit 

3. Agenda
 Characteristics of public facing sites
 Why SharePoint Publishing Infrastructure?
 Caching files
 Output cache
 Using CDN-s

4. Session objectives
After this session you should understand:
 performance problems of public facing
sites
 how caching works in SharePoint
 how to plan and configure caching
 how to measure cache

5. Characteristics
 Accessible by anonymous users
 Harder to estimate server load
 Mostly one-way communication
(this is what MS thinks)
 Different needs (design, SEO)
 Different publishing process

6. SharePoint Publishing Infrastructure
 Targeted to public web sites and corporate
in-house portals
 Perfect fit for corporate information
publishing
 Publishing workflows
 Different optimization options

7. Caching files

8. Request to page
 Every file reference
means new request
 Most files are kept in
SharePoint libraries
 Professional design
means hundreds of
files
 Plus dynamically
loaded files

9. Same time in server...

10. What is BLOB cache?
 Files from doc libraries are cached to
front-end servers
 Perfect fit if per page load many requests
are made to server
 Perfect fit also for large files
 Support for e-tags
 You save:
◦ Some database connections and queries
◦ Loading files to database server memory
◦ Moving files from db server to web server
◦ Some traffic

11. How to optimize
 Keep blobs on separate physical disk
 Every front-end server must have its own
blobs folder or disk
 If disk crashes or you delete files from
blob cache you must reset blob cache
 Blob cache may slow down your site for a
moment when files are copied to disk
 When measuring start from second
request

12. Output cache

13. Caching pages
 Built on ASP.NET caching
 Output cache is served from memory
 Possible to define cache profiles
 Profiles can be assigned to page layouts
 Code-based policies
 Possible to define non-cached areas
(called also donut hole caching)

14. Don’t over-cache!
Again: Output cache uses server memory!
 Morning:
 Noon:
 Afternoon:
 Evening:

15. How to measure cache?
 Use ASP.NET and SharePoint performance
counters
 Make sure counters are not updated too
often – it puts markable load on server
 Measuring must be long enough to see
how cache is actually used
 No app-pool recycle or iisreset
 If ~85% of requests are served from
cache you are okay

16. Output cache
Data from real-life scenario

17. About measuring process
 Performance counters on production
 Interval 15 seconds
 Counters:
◦ Total number of objects added
◦ Total object discards
◦ Cache hit count
◦ Cache hit ratio
 Duration: 12h (work hours fully covered)
 No interruptions

18. Results

19. Content Delivery
Networks (CDN)

20. CDN servers

21. Using CDN-s
 Files are hosted on other servers
 Users get files from closest servers
 Many popular JS libs are available in
Google and MS CDN servers
 You can build your own CDN using
Windows Azure services
 Point of trouble: wider internet outage

22. Q&A

23. Thank you!