Having a very odd problem where a fairly standard recursive sitemap XSLT macro (pretty much the one that comes out of the box, with an additional name() check to exclude certain docTypes from the map).
On some sites, it works fine, renders a sitemap for 1000's of pages in less than a second. On a couple of sites though, small sitemaps (<50 pages) are taking 2 - 3 minutes to render.
Wierdly, if I add an empty <xsl:text> block after the recursive call, the macro renders at normal speeds.
Anyone come across this before and got any ideas what might be causing it?
@Lee, I've taken off all of the library calls, and it makes no difference! I'm a bit stumped too, only thing I can think of is its to do with the output, possibly something to do with rendering out the output of the transform? It's definitely the @updateDate field that's the problem (see this post for others with the same issue: http://our.umbraco.org/forum/developers/xslt/21607-Slow-XSLT-for-Sitemap, Laurence G is the one who spots updateDate as the culprit, my own research confirms this, scroll to the lsat page for my detailed findings!)
@Chriztian, I wish! Then I could just switch it off :P. The normal ul based sitemap works fine on the site, it seems to be adding the @updatedDate to the google sitemap that's the problematic field. I'll try your method though, and see if it makes a difference!
OK, reading through the other post I'm completely baffled. If it is indeed the case that adding a text node after the @updateDate field will speed up the generation of the result tree, I'd say it's a serious bug in the XSLT processor (MSXML).
I could imagine there'd be a difference in using the "drawNodes" approach (calling templates recursively sending a lot of subtrees along for many levels) versus the apply-templates approach (of which I'm certain the processor is highly optimized for) - but that doesn't at all explain the @updateDate issue.
Very curious to find out about this...
Anyone (@Lee ?) tried to debug this in Visual Studio using a giant Umbraco.config file?
Hmmm, more sleuthing reveals that the problem gets worse the deeper in the tree that you traverse. Only listing level 2 nodes (everything under the homepage) is mad fast. Up it to level 3 nodes and it gets slightly slower, 4 is super slow and anything deeper than that and it takes almost a MINUTE to render.
@Chriztian, I'm going to try your approach now and see if that works any better! Will keep this thread updated!
@Chriztian, looks like the performance issue is still there. I'm also having trouble getting the exclude template be picked up. It always seems to match the more general template rather than the exclude one, regardless of what order I have the template blocks in inside the XSLT file....... Any ideas what's going on there?
Sitemap Macro Running Slow?
Having a very odd problem where a fairly standard recursive sitemap XSLT macro (pretty much the one that comes out of the box, with an additional name() check to exclude certain docTypes from the map).
On some sites, it works fine, renders a sitemap for 1000's of pages in less than a second. On a couple of sites though, small sitemaps (<50 pages) are taking 2 - 3 minutes to render.
Wierdly, if I add an empty <xsl:text> block after the recursive call, the macro renders at normal speeds.
Anyone come across this before and got any ideas what might be causing it?
Hi Tim,
Hmmm... taking a complete stab in the dark - thinking that it could be related to the "umbraco.library" calls (IsProtected, IsLoggedOn)?
Can't say why adding an empty <xsl:text> would speed up the rendering ... very strange!
Cheers, Lee.
Hi Tim,
You sure you didn't leave uBrokeIt on those :-) ?
Try the "SSS" and see how it performs:
then add an empty template for the types you want to exclude, e.g.:
/Chriztian
Thanks Guys!
@Lee, I've taken off all of the library calls, and it makes no difference! I'm a bit stumped too, only thing I can think of is its to do with the output, possibly something to do with rendering out the output of the transform? It's definitely the @updateDate field that's the problem (see this post for others with the same issue: http://our.umbraco.org/forum/developers/xslt/21607-Slow-XSLT-for-Sitemap, Laurence G is the one who spots updateDate as the culprit, my own research confirms this, scroll to the lsat page for my detailed findings!)
@Chriztian, I wish! Then I could just switch it off :P. The normal ul based sitemap works fine on the site, it seems to be adding the @updatedDate to the google sitemap that's the problematic field. I'll try your method though, and see if it makes a difference!
OK, reading through the other post I'm completely baffled. If it is indeed the case that adding a text node after the @updateDate field will speed up the generation of the result tree, I'd say it's a serious bug in the XSLT processor (MSXML).
I could imagine there'd be a difference in using the "drawNodes" approach (calling templates recursively sending a lot of subtrees along for many levels) versus the apply-templates approach (of which I'm certain the processor is highly optimized for) - but that doesn't at all explain the @updateDate issue.
Very curious to find out about this...
Anyone (@Lee ?) tried to debug this in Visual Studio using a giant Umbraco.config file?
/Chriztian
Hmmm, more sleuthing reveals that the problem gets worse the deeper in the tree that you traverse. Only listing level 2 nodes (everything under the homepage) is mad fast. Up it to level 3 nodes and it gets slightly slower, 4 is super slow and anything deeper than that and it takes almost a MINUTE to render.
@Chriztian, I'm going to try your approach now and see if that works any better! Will keep this thread updated!
@Chriztian, looks like the performance issue is still there. I'm also having trouble getting the exclude template be picked up. It always seems to match the more general template rather than the exclude one, regardless of what order I have the template blocks in inside the XSLT file....... Any ideas what's going on there?
Hi Tim,
Yeah - I always forget that when posting to the forum :-) Should have learned by now, though...
To force using the "exclude" template, add priority="1" to the template, like this:
/Chriztian
Still doesn't work! I call the following in my initial match:
<xsl:apply-templates select="$rootPage/descendant::*[@isDoc and not(umbracoNaviHide = 1)]" />
The two templates I have are:
<xsl:template match="*[@isDoc][not(umbracoNaviHide = 1)]" priority="2">
<url>
<loc>
<xsl:value-of select="$url"/>
<xsl:value-of select="umbraco.library:NiceUrl(@id)"/>
</loc>
<lastmod>
<xsl:value-of select="./@updateDate" />
<xsl:text>+00:00</xsl:text>
</lastmod>
<priority>
<xsl:choose>
<xsl:when test="./googlePriority > 0">
<xsl:value-of select="./googlePriority"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="0.5"/>
</xsl:otherwise>
</xsl:choose>
</priority>
</url>
<xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="DateFolder | ContentPage" priority="1">
<url>IGNORED!!!</url>
</xsl:template>
</xsl:stylesheet>
The second template is never matched, even though there are elements there which are DateFolder or ContentPage doctypes.......
Any ideas?
is working on a reply...