Decreasing Episerver Startup Time
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 ToolsTo 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:
http://www.website.com/episerver/Shell/Debug/ShowTimeMetersIn 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:
MiniProfilerThe 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.
GlimpseIf 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.
Monitoring ToolsYou 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 ProblemAfter 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.
Common MistakesAfter 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.