4 Comments

A fast, first-page load time for a web application (& in particular a Kentico CMS installation) is disproportionately dependent on the application already being running, and any slow to load items being pre-cached.  This post describes how using a monitoring service like Pingdom can help with this (& usefully also notify you when there are problems with the site).

Factors Affecting First-Page Load Time

When an ASP.NET application is running in a shared application pool (typical for most inexpensive website hosting) your application may be unloaded if it hasn't had any traffic for a while.  When the next request comes in, the application has to be reloaded before the page request is processed.  This can take an appreciable amount of time.  However, if the application is already running, this potential delay is eliminated (this is rather like the difference between creating a new Word document with or without Word already being running).

Data stored in a memory cache is available in a fraction of the time it would take to get the same data from disk or (worse) a database.  So it makes sense to have any frequently required, slow to load content already in cache, ready for the next person who requests it.  Unfortunately the cache can be cleared, fully or partially, by ASP.NET.  For example, if the application restarts (which may happen at any time if running in a shared application pool) the cache will be emptied.  And if system memory is running low, items may be ejected from the cache so the memory can be used elsewhere.  This is of particular significance for Kentico CMS, which makes extensive use of cached data (otherwise requiring a lot of database activity to process & build pages).

Many other factors can impact the page-load time (for example the size & number of requests required to get the page to the browser) but here I am just considering the most signifcant issues which are unique to the time it takes to load the first page a user requests.

Regularly poll your site to Keep It Alive

One of the simplest solutions to address the two issues above is to regularly request pages from your website.

If a request is made to your site every 5 minutes, then it is unlikely that the application will be unloaded (& if it has been your request will reload it) and if any items are missing from the cache they will be added back in.

For Kentico CMS this can make a huge difference.  What Kentico calls "Page Info" (essentially everything that is needed to route a request & know where to find the page content) must always be cached for a decent response time.  So regularly requesting anypage will get this common Page Info back in the cache if it is missing.

Most Kentico sites have pages that will benefit from their content being cached too.  But since the content will only be cached for a particular page when that page is requested it may be worth including multiple pages in your polling.  For example, you would almost certainly want to request the home page regularly to ensure its content is cached, but if you have other pages that are slow to load from the database that you want to always be delivered quickly from cache, you could include them too.

What do I need to do?

The first thing to check is the frequency of all visits to your site.  If a page request is coming in to your home page at least once every 5 minutes throughout the day, then your site will probably already be fine.

If less than this (particularly out of office hours) then the site may benefit from being regularly polled.

Using Pingdom

Pingdom is actually a monitoring service which in itself gives you very useful information about the uptime & page response times of your site (& will alert you to any problems).  However, it acheives this by regularly requesting one or more pages from your website (for example, every 5 minutes).  So it has a useful side-effect for us that it will keep the application alive, and keep the content cached for the page(s) being requested.

At the time of writing, Pingdom is free for a single web site, but paid for if you want to monitor multiple web sites or web pages.

It only takes a minute or two to sign up for an account and specify the page you want to monitor.  Polling starts almost immediately, and thereafter will keep your site alive ready for visitors.

Using RSS

If your Kentico site includes an RSS page (whether public or just created for this purpose) then you can set up an RSS reader (Microsoft Outlook, for example) to check the page every 5 or 10 minutes.  This achieves the goal of keeping the application live, but doesn't help with caching content for particular pages.

Kentico Caching Configuation

I've been assuming throughout this post that Kentico users have caching optimally configured.  If you are not sure please take a look at Martin Hejtmanek (kentico's CTO) deep-dive blog poston the subject.

Comments

Comment by Helena

Hello Steve,

I am using Pingdom (it should ping my site every 5 minutes). It reports that the site is OK. However, if I access the site after a long time, it takes a long time to load and Event log reports an application start. I have a Free version of Pingdom. Does it make any difference? It seems it does not work as you have described.

Thanks,
Helena

Comment by Steve Moss

Hi Helena

If Pingdom is receiving a page from Kentico, then the application must be running at that point. I've used the free version of Pingdom, and the functionality seems just the same as the paid for version.

If the Pingdom reports are showing the page load time as being normal (a second or two) then it looks like something else is triggering the restart. Suggest you contact Kentico support (or use their forums) if that looks likely.

Steve

Steve Moss
Comment by Brenden

Steve, great article! Question, would the Keep Alive webpart do the same thing as what you describe with Pingdom? I'm using v6.0 and have included that in my master page hoping for the best but haven't published the whole site live yet.

Brenden
Comment by Steve Moss

Hi Brenden

I'm not sure the the "Keep alive" web part will achieve the same. The documentation says its purpose is to ensure the session for the current user doesn't time out (but you can set a long timeout for session in the web.config file anyway, making this redundant in some circumstances). But if the application shuts down, any session stored in memory (the default setting) is lost.

I've not looked at the Keep Alive webpart, so don't know what it will do if the session is lost like this.

I also wouldn't recommend adding it to the Master Page - this means every user of the site will be pinging requests to keep their session alive unnecessarily. Just use it on pages where you want to extend session beyond the value set in web.config.

Hope that helps,

Steve

Steve Moss