Guest Author:"Application is busy under initialization phase"

by: Allan Thræn

Again, I've been reckless enough to lend out blog-space to a bright developer. This time it's Thomas Fritzen from the  partner, Creuna. Here is his post:

 

The following has been experience on EPiServer 5.1.422.269

While developing a medium sized website (40K pages) for a customer, using local EPiServer installations for each developer, and a central database, we experienced quite  a lot of latency in our development environment after each recompile – and often the error “Application is busy under initialization phase” would occur – when trying to click on more than one link or when reloading a page to quickly on the website.

This can be quite a pain – especially in edit mode - and as the number of pages on the website grew, the site took longer and longer to initialize. (3-4 seconds).

To find out why this delay occurred, we enabled the debug mode logging in EPiServer as described in http://world.episerver.com/en/FAQ/Items/How-do-I-create-a-log-in-EPiServer/

This revealed that the culprit was loading the DataFactoryCache with 38000+ elements

2008-12-12 11:53:11,446 INFO  - Passed ValidateEnterpriseLicense

2008-12-12 11:53:11,446 INFO  - Passed InitializeXFormEmail

2008-12-12 11:53:11,446 DEBUG - key=DataFactoryCache.MasterKey, retval=null

2008-12-12 11:53:11,446 DEBUG - key=DataFactoryCache.MasterKey, value=object of type System.Int64, absoluteExpiration=31-12-9999 23:59:59, slidingExpiration=00:00:00, priority=NotRemovable

2008-12-12 11:53:11,446 DEBUG - key=DataFactoryCache.Version, retval=null

2008-12-12 11:53:11,446 DEBUG - key=DataFactoryCache.Version, value=object of type System.Int64, absoluteExpiration=31-12-9999 23:59:59, slidingExpiration=00:00:00, priority=NotRemovable

2008-12-12 11:53:11,446 DEBUG - key=DataFactoryCache.MasterKey, retval=object of type System.Int64

2008-12-12 11:53:11,446 DEBUG - key=DataFactoryCache.Version, retval=object of type System.Int64

2008-12-12 11:53:11,602 DEBUG - key=EPChildrenData:5834, value=object of type EPiServer.Core.PageReferenceCollection, absoluteExpiration=31-12-9999 23:59:59, slidingExpiration=12:00:00, priority=Default

……

2008-12-12 11:53:14,065 DEBUG - key=EPChildrenData:51936, value=object of type EPiServer.Core.PageReferenceCollection, absoluteExpiration=31-12-9999 23:59:59, slidingExpiration=12:00:00, priority=Default

2008-12-12 11:53:14,065 INFO  - Passed DataFactoryCache.Initialize

2008-12-12 11:53:14,065 INFO  - Passed LazyIndexer

These log lines indicate that the cache setting where wrong for our development environment.

To resolve the issue – some reflector and test work – revealed that setting

pageCacheSlidingExpiration="0"

in the siteSettings of web.config removed this caching.

Now load time is about one second including recompile of the C# code.

It seem the default value of "12:00:00" is only good for a production site – or if you are developing a fairly small website. Setting this value to 0 also has the side effect of not caching data locally – so you see the changes that other people in your development team has made to the pages that they work on, without reloading your site locally.

 

Regards, Thomas Fritzen Creuna.dk

12 December 2008


Comments

  1. Interesting results! From what I know, EPiServer will not load any extra data from the database into memory due to enabling the API cache or not. So - your 38000 pages will be read in either case. The really interesting part is that what your results seem to indicate is that looking up a page in the cache is so expensive that it's actually cheaper in time to just go to the database and fetch it! Someone should probably do a bit of profiling on the runtime cache implementation, and possibly the default underlying System.Web.Caching.Cache implementation. If a hashtable has too few buckets, 38000 entries can well cause very timeconsuming lookups. This may be a really good illustration of the problems with making assumptions when optimizing. Optimization should always be the result of real measurments. The real reason may be something else entirely, and I'm hoping someone in the EPiServer team takes a look at this. The other thing you mention, seeing changes when a development team is sharing the same database, can be managed by enabling remote events and treating the development team members as part of a web farm.
  2. Tmqrn9 ykdpodhfzdcj, [url=http://llgrirfccpbz.com/]llgrirfccpbz[/url], [link=http://wcikaazzthoq.com/]wcikaazzthoq[/link], http://ucjeievkatmv.com/
Post a comment    
User verification Image for user verification  
Allan Thræn

About me

I am a product manager @ EPiServer, with a passion for the more geeky side of things. My technical interests are typically focused around user problems, user experience,  search, information management, artificial intelligence and  personalization

On top of this blog I have the blog Allan On Technology and I often crosspost.

DISCLAIMER: Unless otherwise stated in the posts, this blog expresses my personal opinions, experiments and views, not necessarilly the views of EPiServer AB.

 300 page views this week.

 

 

Syndications


Archive


Tag cloud

EPiTrace logger