Views: 7120
Number of votes: 10
Average rating:

Dynamic property performance improvements

I won't give you a background on dynamic properties here. If you don't know about them, this blog post will probably not make much sense to you anyway.

The bad

Dynamic properties in EPiServer CMS has a bad reputation for killing performance. The actual problem is not really when accessing the properties, it is an old design decision that optimizes the "read dynamic property from cache" part. You could probably see this as an effect of a premature optimization where the big picture was not clear before the decision was made.

Getting a dynamic property from cache is extremely fast - yes you do have an overhead compared to "regular" properties, but comparing this to the overall execution time for a page it is close to negligible.

Why is it a bad thing to optimize heavily to what you would regard as the most common use-case for dynamic properties (reading them for a page)?

Well, in order for the "read from cache" to be as fast as possible, we store a short-circuited tree structure in the cache with nodes directly linking only to pages where we have an actual dynamic property definition. This tree needs quite a lot of work to be setup and most of this work is done in the database procedure that gets the data. I e when the cached information is flushed, performance gets bad.

Since we store a partial representation of the tree structure it needs to be flushed as soon as you move or delete a page and that is the core of the dynamic property performance problems.

The good

It's fixed. Yes, it is really fixed now. We no longer flush the cache on move, the actual operation of reading dynamic properties from the database is fast and you should no longer see any bad side-effects of using dynamic properties.

We de-optimized the "read from cache" scenario and that allowed us to simplify the code and data structures. Instead of doing a quick lookup in a hash table, we do a standard "follow the parent chain" loop in order to find pages with dynamic property definitions. This makes the read access for dynamic properties slower than it used to be, but it is still in the <1% range of total page execution time.

The nice side-effect

There is a related optimization that was done, which you may want to use in your code. The default DataFactory.GetPage() API will use the default LanguageSelector implementation, which contains quite a lot of logic for dealing with language falllbacks etc. In some cases you don't really care about the language specific information, in the dynamic property case we just want to iterate over the the parent chain. We therefore have a new NullLanguageSelector which simply uses whatever language is present in the returned PageData object.

To use it yourself you can write code like this:

var page = DataFactory.Instance.GetPage(pageLink, NullLanguageSelector.Instance);

If you make a lot of GetPage calls that uses non-language specific information you may see a fair performance improvement in the range of 5 - 15% for this specfic API.

When can I see the new dynamic property goodness?

In EPiServer CMS 6 R2.

Oct 20, 2010

David.Knipe
(By David.Knipe, 10/20/2010 4:03:24 PM)

Great news that its fixed Magnus. Any news on when we can get our hands on EPiServer CMS 6 R2 or even a beta? I've got some clients that could really benefit from it!

daniel.b.berg
(By daniel.b.berg, 10/20/2010 4:40:26 PM)

Nice! Great work!

lee.crowe
(By lee.crowe, 10/20/2010 7:09:51 PM)

Will this make the following fix http://world.episerver.com/Blogs/Svante-Seleborg/Dates/2010/9/Dynamic-Properties-performance-revisited/ for the netDynamicPropertyTree stored procedure which added an index to the temporary table to improve the performance when loading dynamic properties redundant or will this stored procedure fix be included in the next release?

Svante Seleborg
(By Svante Seleborg, 10/20/2010 8:13:47 PM)

Nice, as you say - "Premature optimization is the root of all evil" ;-)

Could you clarify the following: "We no longer flush the cache on move" - does that mean that you still have a cache, but are smarter about it, or rather there's no cache to flush because you just follow the parent chain on access instead?

If there's no longer any cache, then the temporary table index trick we implemented ( http://world.episerver.com/Blogs/Svante-Seleborg/Dates/2010/9/Dynamic-Properties-performance-revisited/ ) is no longer relevant.

It's still very, very relevant as a hotfix for all existing sites experiencing dynamic property related performance issues. It *really* rocks, up to at least 100,000 pages where it's tried and proven - moving a site from massive troubles to a 100% uptime and drastically reduced response times with that single change.

If you're not ready to wait for CMS 6 R2 and then upgrade, and have these problems, ask your friendly EPiServer representative for a hotfix, or if you're desperate like us - do it yourself. But mind the voided warranty...

(By , 10/20/2010 10:43:45 PM)

This is great stuff! Nice work!

ms
(By ms, 10/20/2010 11:42:19 PM)

@David - I cannot say anything about availability now. You would need to talk to Allan Thraen about that.
@Lee - Yes, this completely eliminates the need (and thus the optimization) of that stored procedure. We no longer need to work with a temp table.
@Svante - The dynamic properties are cached, but the structural info that was previously cached as well is now replaced with parent chain traversal. That means we can keep the cached values even in the face of moves.

Anders Hattestad
(By Anders Hattestad, 10/21/2010 12:19:04 AM)

Is this a step on the way to get versioning for the dynamic properties?

ms
(By ms, 10/21/2010 2:32:36 PM)

@Anders - sorry, but no. I haven't heard much about the need for versioning of dynprops before. Is it to support "time travel" or are there any other requirements that you would need that feature for?

Anders Hattestad
(By Anders Hattestad, 10/22/2010 12:50:57 AM)

Only time travel. hard to explain a customer that if you change a dynamic property its changes forever, but on a page we have a version of it

Magnus Rahl
(By Magnus Rahl, 1/17/2011 11:09:29 AM)

Please take a look at this forum thread, is it a bug caused by this redesign? http://world.episerver.com/Templates/Forum/Pages/Thread.aspx?id=46966&epslanguage=en

Please login to comment.