Magnus Stråle
Oct 20, 2010
  7451
(10 votes)

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

Comments

Oct 20, 2010 02:03 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!

Oct 20, 2010 02:40 PM

Nice! Great work!

Oct 20, 2010 05:09 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
Svante Seleborg Oct 20, 2010 06:13 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...

Oct 20, 2010 08:43 PM

This is great stuff! Nice work!

Oct 20, 2010 09:42 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
Anders Hattestad Oct 20, 2010 10:19 PM

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

Oct 21, 2010 12:32 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
Anders Hattestad Oct 21, 2010 10:50 PM

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
Magnus Rahl Jan 17, 2011 10:09 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.
Latest blogs
Customizing Property Lists in Optimizely CMS

Generic property lists is a cool editorial feature that has gained a lot of popularity - in spite of still being unsupported (officially). But if y...

Allan Thraen | Oct 2, 2022 | Syndicated blog

Content Delivery API – The Case of the Duplicate API Refresh Token

Creating a custom refresh provider to resolve the issues with duplicate tokens in the DXC The post Content Delivery API – The Case of the Duplicate...

David Lewis | Sep 29, 2022 | Syndicated blog

New Optimizely certifications - register for beta testing before November 1st

In January 2023, Optimizely is making updates to the current versions of our certification exams to make sure that each exam covers the necessary...

Jamilia Buzurukova | Sep 28, 2022

Optimizely community meetup - Sept 29 (virtual + Melbourne)

Super excited to be presenting this Thursday the 29th of September at the Optimizely community meetup. For the full details and RSVP's see the...

Ynze | Sep 27, 2022 | Syndicated blog

Preview multiple Visitor Groups directly while browsing your Optimizely site

Visitor groups are great - it's an easy way to add personalization towards market segments to your site. But it does come with it's own set of...

Allan Thraen | Sep 26, 2022 | Syndicated blog

The Report Center is finally back in Optimizely CMS 12

With Episerver.CMS.UI 12.12.0 the Report Center is finally re-introduced in the core product.

Tomas Hensrud Gulla | Sep 26, 2022 | Syndicated blog