We have moved to GitHub Issues
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)
I have the same problem.
Our Website Description:
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.
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.
@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.
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.
@Stephane Perfect! Thanks. I'll look at it this week and report back on this issue with progress etc.
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.
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.
Thanks Morten, will test now
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.
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 :-)
Thanks Morten, it's much quicker - changing a property on a master doctype now takes a couple of minutes rather than 25 !
Hendy, it still takes minutes to save? It should never take minutes... anything more than a few seconds is unacceptable.
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.
@Hendy How many DocTypes do you have?
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 ?
Yes, sure. You have my email, so just send it over when you get a chance.
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.
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.
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.
Type: Performance Problem
Assignee: Morten Christensen
Backwards Compatible: True
Affected versions: 6.0.0
Due in version: 6.0.1