There’s nothing more frustrating than sitting in front of a blank screen waiting for your site to load. The longer your pages take to load the more likely you will lose traffic. On some of the projects I’ve worked on, the project’s start-up time has slowly increased to levels of ‘I want to smash the monitor up if it takes another second to load’ levels. The aim of today’s post is to try and help you identify where the bottlenecks in your Episerver website project live.
Finding Your Episerver Start-Up Bottlenecks – Profiling Tools
To narrow down potential bottlenecks we will need to use a profiling tool, out of the box Episerver comes with a basic profiling tool, you can access it using this URL:
In order to access it, in your web.config you need to set your ‘Epi.DebugView.Enabled property in your app settings to true, like so:
<appSettings> <add key="EPi.DebugView.Enabled" value="true"/> </appSettings>
When you run the tool it will show you the last page load, which will look something like this:
The Episerver profiler, can useful but it is limited. There are a number of more advanced third-party tools available and one that I recommend you experiment with is MiniProfiler If you want more information about mini-profiler, I suggest you read, How To Install MiniProfiler With Episerver.
If you don’t want to use MiniProfiler, then the other major profiling profiler I recommendation is Glimpse. Glimpse provides more features but in a more intrusive way into your website. Glimpse also needs custom configuration otherwise, it will break certain features when you run it in ‘admin’ mode. This intrusive nature is probably the main reason I favour MiniProfiler.
You could also install a tool like NewRelic. New Relic is a tool for monitoring web applications, both server and client side. New Relic on its own can’t do any form of load testing, but you can combine it with plug-in like BlazeMeter to apply load and run tests.
Troubleshooting Your Episerver Performance Problem
After profiling and monitoring, hopefully, you should have some idea where the main bottlenecks in your application start-up live. When you identify an area of code that’s taking too long to load, begin by adding MiniProfiler logging around key areas and start eliminating/commenting out custom code. Comparing your web.config file with a clean Episerver release version can help pin-point any extra modules, or funky things that might be slowing you down. If you see custom HTTP modules or HTTP handlers, comment them out one at a time and see if this has an impact on performance. Again, wrapping this code around Mini Profiler steps can help identify how much load time each area adds.
If this still doesn’t help, it’s time to go a bit more extreme. Make your web page run with just an empty homepage , without any HTML, CSS or JS at all. At this stage, your site should load super quickly. To identify the issue, simply add bits back, one step at a time until your page starts to crawl. When you identify the component(s) within your page that causes the slow down- inspect and refactor the code.
After following this troubleshooting process below lists a few of the more common issues that I’ve encountered:
Too Many Initialization Modules On every project you’ll need certain configuration code to run when your website is loaded for the first time. Episerver provides initialization modules to allow you to hook your custom code into the request pipeline. In some projects, developers can get a bit trigger happy to initialization modules. In your solution do a search for ‘InitializableModule’ and see if you can trim any of the code down.
Too Many Pages On The Same Level Of Hierarchy As Homepage With any CMS it’s good practice to try and keep a neat and organized page hierarchy. On some sites, I’ve seen hundreds of child pages under the home page. Depending on how your site is structured when the site loads, the more objects the API needs to retrieve to work out items like the nav, the longer it will take to load.
Compilation Debug Set to true In your production web.config you should always have the debug set to false.
<compilation defaultLanguage="c#" debug="false" targetFramework="4.0">
Excessive Logging Adding too much Log4Net logging can slow your site down. If you are worried about this you can strip some of this out, or change the logging levels to only show critical errors.
Excessive Datasets Loading large sets of data into memory on start-up can cause performance issues. Over time when the dataset starts to grow, your start-up time can slow down exponentially.
How To Fix It
After you have identified the bottlenecks, you will need to fix it. If you haven’t implemented any caching yet and the slow down in your site is hard to solve easily, then this should be your first call. MVC output caching should be a must have item for all Episerver websites. If you are unfamiliar with the output cache, I suggest you read, Episerver Caching – The Output Cache Explained . If you have more specific caching requirements, then donut caching can be very handy and allows you a more fine-grained approach to caching. If you want to know more about donut caching I suggest you read, How To Implement a Donut Hole Cache In Episerver
and donut caching (although this could have a knock-on effect for your site) and you should be fully versed in the nuances and intricacies.
The aim of today’s post was to point you in the right direction for you to identify and solve performance bottlenecks when your Episerver website starts. Performance issues are always caused by our custom code, so the fixes you will need to implement will vary. I’ve been through this process a lot in the past and I’ve found profiling your website to identify the problem areas is always the best first step. After you have identified the area you need to optimize, coming up with a strategy is a lot easier.
If you haven’t enabled the output cache, do that. In most cases, output caching will fix most of your issues. However, if you just rely on output caching without doing the performance profiling, you’re effectively just putting a sticky plaster over the issue and not fixing the underlining root cause. If this is all a bit too techie for you, feel free to get in contact with me, here and I’d be happy to discuss your issue further with you.