Vulnerability in EPiServer.Forms

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
Maximize performance by uploading your external data to Optimizely Graph

Learn to integrate external data into Optimizely Graph for improved performance, covering data preparation, synchronization, and effective querying.

Surjit Bharath | Dec 6, 2023 | Syndicated blog

Google Read Aloud Reload Problems

Inclusive web experiences greatly benefit from accessibility features such as Google Read Aloud. This tool, which converts text into speech, enable...

Luc Gosso (MVP) | Dec 4, 2023 | Syndicated blog

Google Read Aloud Reload Problems

Inclusive web experiences greatly benefit from accessibility features such as Google Read Aloud. This tool, which converts text into speech, enable...

Luc Gosso (MVP) | Dec 4, 2023 | Syndicated blog

Import Blobs and Databases to Integration Environments

In this blog, we are going to explore some new extensions to the Deployment API in DXP Cloud Services, specifically the ability to import databases...

Elias Lundmark | Dec 4, 2023

Setup new/existing website in DXP integration

EPiCloud v1.3 has been released! You can now upload blobs and database to DXP!

Ove Lartelius | Dec 4, 2023 | Syndicated blog

Join the Work Smarter Webinar: Working with the Power of Configured Commerce (B2B) Customer Segmentation December 7th

Join this webinar and learn about customer segmentation – how to best utilize it, how to use personalization to differentiate segmentation and how...

Karen McDougall | Dec 1, 2023