Can any of the XSLT Gurus help me out here? I have a site with not that much content (< 1mb umbraco.config), but that gets a lot of traffic (3000 - 5000 visits a day). I'm seeing VERY high spikes in CPU, in the region of 70 - 99% when the site is in use.
The site is almost all XSLT, with a couple of legacy user controls using SQL connections, which have all been tested and elimated from the equation.
I've had a look at the page load using umbDebugShowTrace = true, and none of the macros is taking a long time to run, but something's definitely hammering the CPU. It's a tough one to debug locally as well, as our dev server is pretty boss, but the live server is a bit of a heap. Tests on dev don't spike half as much, even under load.
Can anyone give me examples of things that are likely memory hogs, and what you can do to improve the performance? I'm scouring the net as we speak, but some of the articles I'm looking at are quite old, and I'm not sure they'll make that much difference.......
Bah, can't edit my post, also, not using inline code blocks, any external call is to an XsltExtension (and I think there's only one of those, to 301 certain templates, it's not used much). I DO use contains() in a few of my loops in the navigation, and I do use library:GetXmlById() in my navigation macros, as we're using the MNTP to build the different navigation areas on the site.
If I think of anything else funky we're doing, I'll post it here!
My gut tells me its not the XSLT thats at fault, if it was you'd see it in long execution times in the trace output. Might be an idea to look else where. Jumps in CPU are not a bad thing, you are using the CPU as intended as long as performance for everyone is not going through the floor?
The fact if differs from dev to live means something must be different.
Is all the code exactly the same on both machines?
Are all the settings the same?
Are they talking to the same database?
Is the database hosted on one of the machines?
Caching switched on?
Any external XML files you consume each request rather than caching?
Any external calls to webs services etc?
Lots still to check, focus on what is different between the two machines.
- site settings are identical bar a few server specific file paths in config files
- each server has its own database, both SQL 2008, both have DB on same box as the site
- caching is on for the Macros that don't change much
- there's an external XML file from FeedCache (twitter feed) that's pulled in on most pages
- no external web service calls that I know about, its pretty much all umbraco.library stuff and a couple of uComponents extension calls
I'm starting to wonder if it might be something else too. The only main difference between the two boxes (other than that the live box is a 5 year old heap and the dev box is a six month old beast of a machine) is that the live site has a couple of Wordpress instances running on the site. WP can be a bit of a bag of spanners as far as CPU is concerned, so it could be contributing to the problem....... I'm going to take the blogs down "for maintenance" in the morning for about 30 minutes and see if things improve noticeably.
Do you normally do pattern matching for your templates, or for-each loops? There are quite a few for-each loops in the navigation areas, but they're not looping through tons of nodes (whole site is maybe 100 pages or so).
Calling templates is mega powerful but also messes with your head if you don't know what you are doing and also takes alot of time to "reload" into your brain when you revisit it. I find using for-each loops tend to be easier on developers so I got with them 99% of the time to be pragmatic about it.
From what you say about the timings for the macros I really doubt it is the XSLT thats the issue but a little bit of optimising never hurt, grab the quick wins while you are there but don't go silly ;)
One thing raised a flag on my radar: The Twitter feed thing... How is that loaded? Custom extension?
You could try substituting the native document() function for that one, just to see if there's any difference in performance (just haul a URL string in it).
Other things that could cause a slight problem is something that - unfortunately - is seen quite often in Umbraco macros, which is XPaths starting on $currentPage, then going upwards to the top and down from there, a la:
<xsl:for-each select="$currentPage/ancestor-or-self::*[@isDoc]/*[@isDoc and @level = 4]">
<!-- do stuff -->
</xsl:for-each>
While this may seem simple enough, it actually has to perform the level test on way more nodes than necessary - the above would test fewer nodes if written like this instead:
<xsl:for-each select="$currentPage/ancestor-or-self::*[@level = 3]/*[@isDoc]">
<!-- do stuff -->
</xsl:for-each>
Why? - $currentPage is always a Document node, so any ancestor will be as well - so we just select the one at level 3 - (can only be one of those in the ancestor chain) - any Document node that's a child of that one will be a level 4 node, so we don't need to test that either, just that it's a doc.
I'm sure we'd all like to know when you find the real hog, so keep us posted!
If the delay is consistent and reproducable this makes it slightly easier to debug. To help find the area causing the problem you could try:
1. Create a new template (e.g. testingtemplate) copied exactly from the template causing the problems 2. You now have a page you can test against on the Live server without affecting public users: www.yoursite.com/page.aspx ?alttemplate=testingtemplate 3. Is the page still experincing delays? 4. yes, remove a macro/user control etc 5. repeat steps 3-4 until you've identified the problem macro
The Twitter feed is being loaded from: umbraco.library:GetXmlDocument() being passed in a full file path to the document (as it's not kept somewhere you can browse to). Is there a better way of doing this? It's currently cached for about 10 minutes anyway, as the feed isn't updated that often.
XSLT CPU Hogs?
Hi,
Can any of the XSLT Gurus help me out here? I have a site with not that much content (< 1mb umbraco.config), but that gets a lot of traffic (3000 - 5000 visits a day). I'm seeing VERY high spikes in CPU, in the region of 70 - 99% when the site is in use.
The site is almost all XSLT, with a couple of legacy user controls using SQL connections, which have all been tested and elimated from the equation.
I've had a look at the page load using umbDebugShowTrace = true, and none of the macros is taking a long time to run, but something's definitely hammering the CPU. It's a tough one to debug locally as well, as our dev server is pretty boss, but the live server is a bit of a heap. Tests on dev don't spike half as much, even under load.
Can anyone give me examples of things that are likely memory hogs, and what you can do to improve the performance? I'm scouring the net as we speak, but some of the articles I'm looking at are quite old, and I'm not sure they'll make that much difference.......
Any ideas greatly appreciated!
:)
Bah, can't edit my post, also, not using inline code blocks, any external call is to an XsltExtension (and I think there's only one of those, to 301 certain templates, it's not used much). I DO use contains() in a few of my loops in the navigation, and I do use library:GetXmlById() in my navigation macros, as we're using the MNTP to build the different navigation areas on the site.
If I think of anything else funky we're doing, I'll post it here!
My gut tells me its not the XSLT thats at fault, if it was you'd see it in long execution times in the trace output. Might be an idea to look else where. Jumps in CPU are not a bad thing, you are using the CPU as intended as long as performance for everyone is not going through the floor?
The fact if differs from dev to live means something must be different.
And where the hell did my bullet points go? grumble, grumble...
Our seems to eat bullet points for some reason!
:)
In answer to your bullets:
- code is same on both boxes
- site settings are identical bar a few server specific file paths in config files
- each server has its own database, both SQL 2008, both have DB on same box as the site
- caching is on for the Macros that don't change much
- there's an external XML file from FeedCache (twitter feed) that's pulled in on most pages
- no external web service calls that I know about, its pretty much all umbraco.library stuff and a couple of uComponents extension calls
I'm starting to wonder if it might be something else too. The only main difference between the two boxes (other than that the live box is a 5 year old heap and the dev box is a six month old beast of a machine) is that the live site has a couple of Wordpress instances running on the site. WP can be a bit of a bag of spanners as far as CPU is concerned, so it could be contributing to the problem....... I'm going to take the blogs down "for maintenance" in the morning for about 30 minutes and see if things improve noticeably.
Do you normally do pattern matching for your templates, or for-each loops? There are quite a few for-each loops in the navigation areas, but they're not looping through tons of nodes (whole site is maybe 100 pages or so).
Calling templates is mega powerful but also messes with your head if you don't know what you are doing and also takes alot of time to "reload" into your brain when you revisit it. I find using for-each loops tend to be easier on developers so I got with them 99% of the time to be pragmatic about it.
From what you say about the timings for the macros I really doubt it is the XSLT thats the issue but a little bit of optimising never hurt, grab the quick wins while you are there but don't go silly ;)
Hi all,
One thing raised a flag on my radar: The Twitter feed thing... How is that loaded? Custom extension?
You could try substituting the native document() function for that one, just to see if there's any difference in performance (just haul a URL string in it).
Other things that could cause a slight problem is something that - unfortunately - is seen quite often in Umbraco macros, which is XPaths starting on $currentPage, then going upwards to the top and down from there, a la:
<xsl:for-each select="$currentPage/ancestor-or-self::*[@isDoc]/*[@isDoc and @level = 4]"> <!-- do stuff --> </xsl:for-each>While this may seem simple enough, it actually has to perform the level test on way more nodes than necessary - the above would test fewer nodes if written like this instead:
<xsl:for-each select="$currentPage/ancestor-or-self::*[@level = 3]/*[@isDoc]"> <!-- do stuff --> </xsl:for-each>I'm sure we'd all like to know when you find the real hog, so keep us posted!
/Chriztian
If the delay is consistent and reproducable this makes it slightly easier to debug. To help find the area causing the problem you could try:
1. Create a new template (e.g. testingtemplate) copied exactly from the template causing the problems
2. You now have a page you can test against on the Live server without affecting public users: www.yoursite.com/page.aspx ?alttemplate=testingtemplate
3. Is the page still experincing delays?
4. yes, remove a macro/user control etc
5. repeat steps 3-4 until you've identified the problem macro
It's old-school debugging!
Hi @Chriztian, thanks for the advice!
:)
The Twitter feed is being loaded from: umbraco.library:GetXmlDocument() being passed in a full file path to the document (as it's not kept somewhere you can browse to). Is there a better way of doing this? It's currently cached for about 10 minutes anyway, as the feed isn't updated that often.
Tim,
Did you ever find out what the true cause of your problem is/was? We are seeing spikes of 100% CPU with no apparent reason.
is working on a reply...