U4-1714 - Editing of Document Types in v6.0.0 is Slow

Created by Hendy Racher 14 Feb 2013, 14:48:48 Updated by Shannon Deminick 16 Mar 2013, 01:01:11

Relates to: U4-1750

Relates to: U4-1764

saving changes, such as adding / removing properties and renaming tabs can take minutes - if there are child document types, it can take much longer again.

(tested with both local and remote databases)

4 Attachments

Download Test_0.1.zip


Stéphane Bouchard-Pagé 15 Feb 2013, 13:57:20

I have the same problem.

Our Website Description:

  • There is nothing installed on the Web server, except Umbraco.
  • There are about 2000 nodes.
  • There are approximately 30 Document Types.
  • There is a main document type with maybe 20 Document Types children.

When I make a change in the Document Type Master and I save thereafter, processor activity rises suddenly (Core I5!). I can wait about 2 to 3 minutes before the speech bubble appears.

I attached some pictures of activities.

Simon Steed 15 Feb 2013, 16:43:42

We have this problem also - we have a base doc type with one property, another4 doc types inherited from that and another 5 inherited from one of those. Just hitting save without any changes is taking over 2.5 minutes to run, this is just not acceptable performance.

Morten Christensen 15 Feb 2013, 18:13:23

@Stephane would it be possible for you to package up your document types in a normal umbraco package and email it to me? Would give me a better ground for testing and correcting the issue.

Stéphane Bouchard-Pagé 15 Feb 2013, 21:48:30

I attached the zip file here. I added the file access for members of the "core".

Change a property on the master document type and save it.

Morten Christensen 18 Feb 2013, 16:49:27

@Stephane Perfect! Thanks. I'll look at it this week and report back on this issue with progress etc.

Morten Christensen 19 Feb 2013, 15:09:54

Okay, I believe I found the main reason for the Document Types being so slow. A few corrections made it a gazillion times faster :)

For future reference, the main reason why saving doctypes was so slow was because each of these 5 properties (on a ContentType) Alias, Name, IconUrl, Description and Thumbnail triggered ContentType.FlushFromCache(id), which first removes it self from the cache and then loads all DocumentTypes as a list and loops through that list to find all DocumentTypes that has a MasterContentType with the same id as the one that is currently being flushed from cache. This is a recursive method, so for each child that is flushed the same list is looped through and that is not a cached list either, so it would be quite a hit on the db. So all in all very inefficient, and I'm a bit surprised this hasn't be a bigger issue for v4.

Its also a fun little calculation: Given that you have 52 DocTypes, where 26 of them have a MasterContentType I think the load for saving the master DocType would be something like this (very rough): 5*(52 + (26 * 52)) = 7020 + some additional stuff occurring when the actual object is saved, as the calculated number is just for setting the five properties.

Morten Christensen 19 Feb 2013, 15:33:46

I have pushed a nightly build, so if any of you have time to verify that performance for DocTypes has improved then please download this build: http://nightly.umbraco.org/umbraco%206.0.1/UmbracoCms.6.0.1-build.18.zip and overwrite the assemblies in your bin-folder with those from the zip. The build is stable and, so it should be perfectly safe to apply.

Simon Steed 19 Feb 2013, 15:47:33

Thanks Morten, will test now

Stéphane Bouchard-Pagé 19 Feb 2013, 15:52:10

Thank you very much! For me, the performance has really improved.

Now, to save the master document type, it take just 6 seconds instead of several minutes.

Simon Steed 19 Feb 2013, 16:18:57

Working nicely for me, thanks Morten - only problem we have now (and not sure if related), is previously removed properties can no longer be added i.e. Page Title was removed. We can no longer add this property and get the error Property Type Already Exists. Creating new properties works great :-)

Hendy Racher 20 Feb 2013, 17:02:48

Thanks Morten, it's much quicker - changing a property on a master doctype now takes a couple of minutes rather than 25 !

Nicholas Westby 20 Feb 2013, 17:20:00

Hendy, it still takes minutes to save? It should never take minutes... anything more than a few seconds is unacceptable.

Hendy Racher 20 Feb 2013, 17:33:17

Hi Nicholas, yes I quite agree - I'm guessing the best approach will be to log more detailed issues here, so it's easier to identify the problem areas.

Morten Christensen 20 Feb 2013, 17:51:13

@Hendy How many DocTypes do you have?

Hendy Racher 21 Feb 2013, 13:09:28

Hi Morten, there are 11 docTypes at the top level and another 22 at the 2nd level, so a fairly flat structure of 33 docTypes in total. Can I send you the database ?

Morten Christensen 21 Feb 2013, 13:12:48

Yes, sure. You have my email, so just send it over when you get a chance.

Andy Butland 22 Feb 2013, 10:38:52

Just commented on [http://issues.umbraco.org/issue/U4-1764#comment=67-5650 U4-1764] - I think there's at least one of the current three calls made to the save method that could be removed. Not sure exactly when the cache reloads occur but if it's between these save method calls could be that'll shave a further third off the time.

Morten Christensen 25 Feb 2013, 15:43:06

I have fixed a related issue (U4-1764), which should reduce the number of times a DocumentType is Saved from 3 to 1 when clicking save in the backoffice. This should also help reduce the time it takes to save a DocumentType. I have looked at the Database from Hendy, but there was nothing that would influence perf. as far as I could tell. But it would be worth trying to upgrade to latest nightly has it has additional changes from last time this issue was marked as fixed.

Shannon Deminick 16 Mar 2013, 01:01:11

I've just happened to find this code as well since I'm trying to streamline the way that cache is generally handled in umbraco so that it works properly and consistently in load balanced environments. I just think it's extremely ironic that having cache is supposed to speed things up, but in this case it is actually slowing things down due to having to clear it!! I'll keep digging through this code but I am starting to wonder if all of this cache stuff is actually needed or if it was put in place a long time ago because someone assumed it would be better. After reviewing how a lot of this caching is handled (especially based around document types), we have an immense amount of caching happening that I'm sure we probably don't need.

Priority: Major

Type: Performance Problem

State: Fixed

Assignee: Morten Christensen

Difficulty: Normal

Category: UI

Backwards Compatible: True

Fix Submitted:

Affected versions: 6.0.0

Due in version: 6.0.1


Story Points: