I've got a site with 7000 nodes now and with the publish of the rootnode it takes alot of time to publish. After looking at the Umbraco code it noticed in the publish funtion this code:
foreach (var descendant in _document.GetDescendants().Cast<Document>().Where(descendant => descendant.HasPublishedVersion())) library.UpdateDocumentCache(descendant.Id);
That's where all the time i spent because it the foreach runs over every node there is. Now i don't understand why all the descendants are beeing updated? The node itself was updated, and the children, where nothing has been changed, are also being done? and it's also only the cache, not the database.
I think that Umbraco already looked at this point because it's a problem that alot of people run into. But i like to understand why things are done i some way.
Ok now know the reason.. it's because after a unpublish all the childs get deleted from the cache. Still i think it's way to slow, isn't there a smarter way to work with this? In example with every save place the node always to the cache and add a property published? that way you don't have to delete all those nodes.
Yes, I was trying to say that, they are unpublished because the parent is unpublished.
You never (ever!) want anything in the cache that is not actually published because it is WAY too easy to forget checking if a node is unpublished while you're putting content in your templates.
That said, if you can come up with a smarter way, we're all ears! :-)
I made a extra check in the publish function so if it's already published it doens't have to run through all the children (what makes it slow), this sounds logic to me but i really like to hear Sebastiaan opinion! (and maybe he can put it also in version 6! (if it works))
protected void Publish(object sender, System.EventArgs e) { if (Page.IsValid) { if (_document.Level == 1 || new cms.businesslogic.web.Document(_document.Parent.Id).PathPublished) { Trace.Warn("before d.publish");
bool alreadyPublished = (new umbraco.NodeFactory.Node(_document.Id).Id != 0);
if (_document.PublishWithResult(base.getUser())) {
Ps. I've also ported it to v4 now, so when 4.11.4 comes out you'll be able to enjoy a faster backoffice there as well (sorry I have no release date for it yet).
Backend slow when publish rootnode
I've got a site with 7000 nodes now and with the publish of the rootnode it takes alot of time to publish. After looking at the Umbraco code it noticed in the publish funtion this code:
foreach (var descendant in _document.GetDescendants().Cast<Document>().Where(descendant => descendant.HasPublishedVersion()))
library.UpdateDocumentCache(descendant.Id);
That's where all the time i spent because it the foreach runs over every node there is. Now i don't understand why all the descendants are beeing updated? The node itself was updated, and the children, where nothing has been changed, are also being done? and it's also only the cache, not the database.
I think that Umbraco already looked at this point because it's a problem that alot of people run into. But i like to understand why things are done i some way.
I'm testing now with the loop commented out and i don't see any problems yet...
Ok now know the reason.. it's because after a unpublish all the childs get deleted from the cache. Still i think it's way to slow, isn't there a smarter way to work with this? In example with every save place the node always to the cache and add a property published? that way you don't have to delete all those nodes.
Yes, I was trying to say that, they are unpublished because the parent is unpublished.
You never (ever!) want anything in the cache that is not actually published because it is WAY too easy to forget checking if a node is unpublished while you're putting content in your templates.
That said, if you can come up with a smarter way, we're all ears! :-)
Got a other solution?!
I made a extra check in the publish function so if it's already published it doens't have to run through all the children (what makes it slow), this sounds logic to me but i really like to hear Sebastiaan opinion! (and maybe he can put it also in version 6! (if it works))
protected void Publish(object sender, System.EventArgs e)
{
if (Page.IsValid)
{
if (_document.Level == 1 || new cms.businesslogic.web.Document(_document.Parent.Id).PathPublished)
{
Trace.Warn("before d.publish");
bool alreadyPublished = (new umbraco.NodeFactory.Node(_document.Id).Id != 0);
if (_document.PublishWithResult(base.getUser()))
{
ClientTools.ShowSpeechBubble(speechBubbleIcon.save, ui.Text("speechBubbles", "editContentPublishedHeader", null), ui.Text("speechBubbles", "editContentPublishedText", null));
library.UpdateDocumentCache(_document);
littPublishStatus.Text = ui.Text("content", "lastPublished", base.getUser()) + ": " + _document.VersionDate.ToString() + "<br/>";
if (base.getUser().GetPermissions(_document.Path).IndexOf("U") > -1)
UnPublish.Visible = true;
_documentHasPublishedVersion = _document.HasPublishedVersion();
if (!alreadyPublished) {
foreach (var descendant in _document.GetDescendants().Cast<Document>().Where(descendant => descendant.HasPublishedVersion()))
library.UpdateDocumentCache(descendant.Id);
}
}
else
{
ClientTools.ShowSpeechBubble(speechBubbleIcon.warning, ui.Text("publish"), ui.Text("speechBubbles", "contentPublishedFailedByEvent"));
}
}
else
ClientTools.ShowSpeechBubble(speechBubbleIcon.warning, ui.Text("publish"), ui.Text("speechBubbles", "editContentPublishedFailedByParent"));
// page cache disabled...
// cms.businesslogic.cache.Cache.ClearCacheObjectTypes("umbraco.page");
// Update links
}
}
Great idea indeed! Have a look at the last file in this commit.. ;-)
http://umbraco.codeplex.com/SourceControl/changeset/fdfa687e6f41
whoooh! so my comment changed Umbraco core code? Is it also in Umbraco 6?
Indeed it did! #h5yr!
It is only in v6 but I'll look at porting this back to v4 as well. :)
Can you accept it as solved? Then i get karma!
Unfortunately only the topic starter (you) can do that! :) And not for your own topics, sorry. :)
Ps. I've also ported it to v4 now, so when 4.11.4 comes out you'll be able to enjoy a faster backoffice there as well (sorry I have no release date for it yet).
thx! it's our first testsite so i'm not really into a hurry but if i want to use it i can always build my own solution offcourse! :)
is working on a reply...