0% found this document useful (0 votes)
104 views

Performance Troubleshooting

This document provides guidance on troubleshooting performance issues with EPiServer CMS web sites. It discusses common causes of performance problems like large lists of pages, dynamic properties, and FindPagesWithCriteria queries. It also recommends tools for analyzing performance like Fiddler, log parsers, and cache frameworks. The key techniques discussed are optimizing database queries, splitting large lists, caching content strategically, and output caching pages where possible.

Uploaded by

Niels Brinkø
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
104 views

Performance Troubleshooting

This document provides guidance on troubleshooting performance issues with EPiServer CMS web sites. It discusses common causes of performance problems like large lists of pages, dynamic properties, and FindPagesWithCriteria queries. It also recommends tools for analyzing performance like Fiddler, log parsers, and cache frameworks. The key techniques discussed are optimizing database queries, splitting large lists, caching content strategically, and output caching pages where possible.

Uploaded by

Niels Brinkø
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 28

Performance Troubleshooting EPiServer CMS Web Sites

Steve Celius EPiServer Geek

The Different Approaches to Performance


This presentation focuses on troubleshooting existing sites with performance problems
- Finding the cause and what you can do about it - The tools you need, and the common causes

Performance is much much more


- Clientside (everything not in your aspx) can be 80% of the download time (when youre not having server trouble) - Ill cover this the next time

The cost of fixing performance problems


Cost High

Intermediate

Low Content Infrastructure Code

Thanks to Stuart Tuppert

Finding the slow parts of your site


Analyse IIS Logs
- Check time_taken, # requests per hour / min (find the peaks) - Check for errors (404 / 500 status)

LogParser & Visual Log Parser


- Find the most requested pages - Find errors and long running requests - Easier with Visual LogParser

Use Fiddler Performance Monitor


- Lots of information on the net - Check cpu, req/s and req. queue

Common Performance Problems

The Large List Problem


Large collections of pages will kill performance Understanding the cache is important
- GetPage / GetChildren gets copies of PageData objects - Memory and CPU intense (lots of allocations and deallocations)

Dynamic Properties are they really neccessary? Pages with large strings (MainBody) is also a problem News archives will slowly kill your site Edit mode, expanding the tree loads two levels

Key Points
The devil is in the details
- You dont TRULY know until you have profiled

Things changes with content


- What does not hurt you today might hurt you tomorrow

Make sure you optimize the important things

Fixing it!
Split up page lists with more then 250 pages into subtrees
- Why 250? Practical reasons for editors - Use Date Containers (/News/2007/June/My-news-article) - Moving pages using code is easy
You dont even need to recompile (no code behind file neccessary). See ArchiveBuilder.aspx If there are many pages, it will take some time

Cache the list Move Dynamic Properties to the Start Page This problem has less impact in CMS 5

10

FindPagesWithCriteria (FPWC)
The most resource intensive operation in EPiServer Very useful, and most sites need it It will search the database, returning all pages that match the criterias

With great power comes great responsibility

11

Fixing it!
Use log4net to detect FPWC calls
- Log all FPWC calls to one file, with page id and search ref

Limit the use of FPWC


- Always think of alternative solutions

- Limit the count of returned pages. The database call is not the problem, working with a large resultset is

Cache what you can cache


- Enter EPiCode Cache Framework...

12

EPiCode Cache Framework for EPiServer 4


All sites will have some complex and/or heavy queries (not only FPWC) You should recognize them when you write the code Prevent these queries to run too often, cache the result Designed for low impact on existing code Download from:
- www.coderesort.com/p/epicode/wiki/CacheFramework

13

Use output caching


Configurable, turn on in web.config Will cache the html output from your pages Can give you extreme performance Whole cache is invalidated on page publishing Not available for logged in users and POST VaryBy dont vary by browser if you do not have to /3GB in boot.ini (?) It wont fix your problems though

15

Beware of what you cannot see


RSS Feeds in particular
- Long lists, requested often - Check the IIS log file - Use the cache framework

Bots, Crawlers and Spiders


- They might fill our output cache - Will visit the uninteresting pages, like the sitemap and news archive. Pages you hope no one visits

16

Scale out
Buy more hardware Load balance on several servers Especially if the load is the problem Requires cache invalidation and file sync Session state (are you using it?)
- State Server or SQL Server

17

Migrate to EPiServer CMS 5


You will need to rewrite some of the code The Migration Tool helps with data migration
- This is another presentation altogether

See Marek Blotnys excellent blog post on EPiServer 5 vs. EPiServer 4.61
- CMS 5 scales much better

18

Important Tools
Fiddler

JetBrains DotTrace
WebLoad / Jmeter / WAPT Load Testing log4net Trace Diagnostics IIS Diagnostics ASP.NET Viewstate Helper Performance Viewer (Windows) LogParser & Visual Log Parser IIS Traffic Monitor

19

Special offer to all EPiServer Developer Summit 2008 attendees Extended trial period (10 30 days) Offer lasts for 30 days from now!

Read more, download evaluation and order on: http://www.jetbrains.com/profiler


Eval and Coupon code:

b4zLrhD/g23bNieHrY8oV6EIezUiCzad

20

Misc...

21

Release Mode
Compile the site in Release Mode (in VS) <compilation debug=false /> in web.config This will give you ~10% performance gain ASP.NET will not time out with debug = true
- Just as important as the performance gain

WebResources.axd scripts can be cached Site will use less memory

22

Enterprise Gotcha
Same source code, many different web sites
- One place to deploy code - One config file to update

But...
- Config changes will restart all sites
This is heavy lifting!

- Logging with log4net is a pain


All sites uses same config, with file locking, first site to start wins. Without locking, log file is a mess

- One change affects all sites, needs recompiling

23

Enterprise Gotcha, contd.


Use deployment scripts to copy files to all sites
- With delays to allow recompilation and startup peaks - This also goes for web.config

24

IIS Settings
Log more
- Review the IIS log settings. Turn on most log settings - Remember time-taken

Process Recycling dont rely on it


- It will only help on memory or resource leaks, temporarily
- More often used on .NET 1.0/1.1 sites than 2.0 and up

Web Gardens
- No, no and no! It can actually hurt performance

25

Minimize Viewstate
Think Green - Save Bandwidth

www.binaryfortress.com/aspnet-viewstate-helper

27

Links
Performance Tuning and Optimization of EPiServer CMS (Fredrik Haglund) EPiServer 5 vs. EPiServer 4.61 part I - GetPage() (Marek Blotny) The challenges of a high traffic site with EPiServer (Adam Najmanowicz) Performance Pitfalls in EPiServer (Mats Hellstrm) The Output Cache - When and Why (Daniel van den Tempel) Caching Custom Data in EPiServer EPiServer Labs

28

Per Request Cache


Dont do expensive operations more than once in a request Example:
- Checking if the current page is in a given structure

Refactor into utililty methods


Keep the impact on existing code low Store in HttpContext.Current.Items
- Request bound, thread safe

29

IIS Traffic Monitor


Analyses IIS log files on the fly Simple and quick to use Uses Log Parser 2.2

http://niknak.org/software/IIsTrafficMonitor

30

Use Fiddler to see real traffic


Server performance is important, but dont neglect the client side performance Check the Yahoo Performance Blog (and YSlow)
- Percieved performance is also important!

Make sure the clients cache effiently

31

32

You might also like