we're using the Cultiv Search Engine Sitemap for our Umbraco installation which has 4 separate sites. One of them needed to be https, so I created an extra template and changed the urlPrefix. This sitemap now takes 5 min to load (the other 3 are fine), does anyone know why?
Are you using the Razor or XSLT version? Try to add ?umbDebugShowTrace=true to the URL and see what's actually taking so long. I can't think of any reason this would be different for https, it's executing the exact same code..
We're using XSLT, and the debug trace shows the following error: "This page contains the following errors: error on line 7 at column 1: Extra content at the end of the document Below is a rendering of the page up to the first error.". It's actually showing the same error for the other sites who's still on http, but they're not showing as much content. I'll see if I can figure out what's going. I'm new to umbraco so don't know the ins and outs of it yet, and this is an existing project that I've joined so don't know much about the setup yet.
Make sure to move the xml definition right next to the content placeholder. The xml definition should be the first character in your site. It's pretty crazy, but it HAS to be like this for it to produce valid xml:
In the trace you will also see timings in the last column, scroll through that and see where it makes big jumps. That's where the slowdowns actually happen, which could help narrow down the search.
The xml definition is next to the placeholder, so it must be something else that causes it.
The page won't render the trace (I'm guessing because it's html code in xml, and that's probably what the error I was getting was referring to). I can see the trace if I view source though, and it looks like the problem is happening when performing transformation:
I've digged some more, and I'm guessing this actually has nothing to do with Cultiv Search Engine Sitemap or the fact that it's https (sorry!), but simply that the 3 sites with http only don't have as many pages as the https one. The umbraco xml file is around 6 MB.
Sorry for wasting your time, I'll keep reading to see if I can get the file size down and hopefully it'll work then. Thanks for looking into this for me!
Whoa, well the good news is that the sitemap indeed is fast as can be. I'm just wondering what that first macro you have there is doing, that's a hell of a load time..
Just try to remove macro's in the page 1 after another to see which one is causing the load and then start debugging that one to see at what point in the code you get this long halt.
Right, I've found the solution! There were no other macros on the page, but I downloaded the CultivSearchEngineSitemap.xslt file from live (I was testing on dev and staging) and it turns out that file has been modified. I don't know if that's an earlier version of the file, or if someone did specific modifications for our sites (whoever installed it did it directl on live and didn't check it into SVN so it's impossible to say what's happened to the file). If I replace the dev and staging files with the file from live it's quick as a flash! Thank you so much for your help! :)
This is a screengrab from Beyond Compare where you can see the differences:
Aha, weird. The file on the right seems to be the original version. One thing that might actually cause problems (come to think of it) is maxLevelForSitemap. That just says: when there's children on this node, drill down until you get to the 100th childnode before you continue to the next node (and then go 100 levels deep again).
So yeah, if you have very many nodes, and a very deeply nested structure that might be a problem. Still XSLT is incredibly fast, so I'm not sure that would be it. Might be something hidden that I can't see in your diff that's causing the problem.
Yep, the file on the right is the version I downloaded from here and that we had on dev and staging, the one on the left it what we had on live. I did try to change the maxLevelForSitemap but didn't have any effect. I wish the person who changed it had documented why, but that's life hey. :)
Well.. no closure for me, if maxlevel didn't help then I don't see a great deal of difference, just two things:
1. I'm using umbraco.library:FormatDateTime and that's been removed in your version 2. I'm using * a lot, which has been replaced with "node" in your version (I use * so the xslt will work for both the old and the new xml schema)
I can't imagine these would make a big difference.. but apparently they do.
Https version takes ages to load
Hi,
we're using the Cultiv Search Engine Sitemap for our Umbraco installation which has 4 separate sites. One of them needed to be https, so I created an extra template and changed the urlPrefix. This sitemap now takes 5 min to load (the other 3 are fine), does anyone know why?
Thanks in advance!
Are you using the Razor or XSLT version? Try to add ?umbDebugShowTrace=true to the URL and see what's actually taking so long. I can't think of any reason this would be different for https, it's executing the exact same code..
We're using XSLT, and the debug trace shows the following error: "This page contains the following errors: error on line 7 at column 1: Extra content at the end of the document Below is a rendering of the page up to the first error.". It's actually showing the same error for the other sites who's still on http, but they're not showing as much content. I'll see if I can figure out what's going. I'm new to umbraco so don't know the ins and outs of it yet, and this is an existing project that I've joined so don't know much about the setup yet.
Make sure to move the xml definition right next to the content placeholder. The xml definition should be the first character in your site. It's pretty crazy, but it HAS to be like this for it to produce valid xml:
In the trace you will also see timings in the last column, scroll through that and see where it makes big jumps. That's where the slowdowns actually happen, which could help narrow down the search.
The xml definition is next to the placeholder, so it must be something else that causes it.
The page won't render the trace (I'm guessing because it's html code in xml, and that's probably what the error I was getting was referring to). I can see the trace if I view source though, and it looks like the problem is happening when performing transformation:
I've digged some more, and I'm guessing this actually has nothing to do with Cultiv Search Engine Sitemap or the fact that it's https (sorry!), but simply that the 3 sites with http only don't have as many pages as the https one. The umbraco xml file is around 6 MB.
Sorry for wasting your time, I'll keep reading to see if I can get the file size down and hopefully it'll work then. Thanks for looking into this for me!
Whoa, well the good news is that the sitemap indeed is fast as can be. I'm just wondering what that first macro you have there is doing, that's a hell of a load time..
Just try to remove macro's in the page 1 after another to see which one is causing the load and then start debugging that one to see at what point in the code you get this long halt.
Don't worry about the xml file, 6MB is nothing!
Right, I've found the solution! There were no other macros on the page, but I downloaded the CultivSearchEngineSitemap.xslt file from live (I was testing on dev and staging) and it turns out that file has been modified. I don't know if that's an earlier version of the file, or if someone did specific modifications for our sites (whoever installed it did it directl on live and didn't check it into SVN so it's impossible to say what's happened to the file). If I replace the dev and staging files with the file from live it's quick as a flash! Thank you so much for your help! :)
This is a screengrab from Beyond Compare where you can see the differences:
Aha, weird. The file on the right seems to be the original version. One thing that might actually cause problems (come to think of it) is maxLevelForSitemap. That just says: when there's children on this node, drill down until you get to the 100th childnode before you continue to the next node (and then go 100 levels deep again).
So yeah, if you have very many nodes, and a very deeply nested structure that might be a problem. Still XSLT is incredibly fast, so I'm not sure that would be it. Might be something hidden that I can't see in your diff that's causing the problem.
Anyway, glad it's been solved now!
Yep, the file on the right is the version I downloaded from here and that we had on dev and staging, the one on the left it what we had on live. I did try to change the maxLevelForSitemap but didn't have any effect. I wish the person who changed it had documented why, but that's life hey. :)
Haha! I'm curious though, could you put the badly performing version up on pastebin so I can have a look. I need closure! ;-)
Haha, I was just going to ask if you wanted to see the file with the modifcations on it. :)
Here it is: http://pastebin.com/mSXwER19
That's the version that is fast on our site, the version that was running slow for our site is the official one.
Well.. no closure for me, if maxlevel didn't help then I don't see a great deal of difference, just two things:
1. I'm using umbraco.library:FormatDateTime and that's been removed in your version
2. I'm using * a lot, which has been replaced with "node" in your version (I use * so the xslt will work for both the old and the new xml schema)
I can't imagine these would make a big difference.. but apparently they do.
Indeed: C'est la vie, I suppose ;-)
is working on a reply...