Try our conversational search powered by Generative AI!

Magnus Stråle
Oct 20, 2010
(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


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 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 ( ) 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?

Please login to comment.
Latest blogs
Headless forms reloaded (beta)

Forms is used on the vast majority of CMS installations. But using Forms in a headless setup is a bit of pain since the rendering pipeline is based...

MartinOttosen | Mar 1, 2024

Uploading blobs to Optimizely DXP via PowerShell

We had a client moving from an On-Prem v11 Optimizely instance to DXP v12 and we had a lot of blobs (over 40 GB) needing uploading to DXP as a part...

Nick Hamlin | Mar 1, 2024 | Syndicated blog

DbLocalizationProvider v8.0 Released

I’m pleased to announce that Localization Provider v8.0 is finally out.

valdis | Feb 28, 2024 | Syndicated blog

Epinova DXP deployment extension – With Octopus deploy

Example how you can use Epinova DXP deployment extension in Octopus deployment.

Ove Lartelius | Feb 28, 2024 | Syndicated blog