I have a site set up using Umbraco v4.7.2 and the following packages:
umbraco v 4.7.2 (Assembly version: 1.0.4500.21031)
uComponents v3.0
Umbraco Contour v1.1.11
Google Maps for Umbraco v2.0.2
Tea Commerce v1.4.1.2
The site is setup on Windows 7 Professional running IIS version 7.5.7600.16385 with a quad core i5 2.66GHz CPU and 8 GB of RAM.
With the above spec processor usage for a single page view should bearly register an increase, however I am seeing the following behaviour:
Front End
A single page view on this site causes all four cores of the processor to raise to 30% for about 30 seconds (while the html part of the prepared to send to the browser) and then stick at 100% for at least a further 30 seconds (while the CSS and JavaScript resources are prepared to send to the browser). Total page load time is typically around the 80 seconds mark (see image below)
The above usage is for a single page load on the front end of the site.
Back end
If I load the back end of Umbraco up then I see similar issues. To login to the back end of Umbraco takes about 2 minutes and the processor is locked at 100% for a good minute of that time, once logged in leaving the Umbraco interface loaded in the browser, but without any user interaction the processor usage spikes at arround 80% on a regular interval of exactly 1 minute. See below:
Questions
Has anyone else seen this behaviour?
Any suggestions of where I should be looking for the cause of this?
1) Download the debug symbols from Codeplex for Umbaco and dump them into your /bin folder.
2) Begin a performance analysis with Visual Studio (if you have Pro or Ultimate edition, I think).
The performance analysis shows you exactly which thread is causing your lockup, and when you drill down into it, which methods are being called as part of the render process.
Ah. In which case I'm gonna shoot round to venue now - gimme 20 minutes :-)
Adding debug symbols on their own will slow first load of the site, cause it has to match symbols to DLLs, so only do it if you plan on walking through the compiled Umbraco DLLs anyway.
Hi. As the first step I would try to view the page with "?umbDebugShowTrace=1" and inspect the timings to find out what stage of the whole page's lifecycle takes so long.
BTW, high CPU load itself is not always a bad thing as long as meanwhile the application itself keeps running fast (however, as I got it it's not the case here) - on the contrary too low CPU load can often point to some serious problems like excessive I/O, deadlocks, etc.
I had tried the debug trace but it didn't show any part of the page as being slow and I didn't recognise the very obvious significance of this (That Umbraco wasn't taking up the time) until I was pointed to the solution to the problem from outside of this forum (Many thanks to Brendan Rice for pointing me in the right direction).
The site had a whole stack of URL redirect rules and the performance issue was with the URL redirect module not with the Umbraco site (http://blog.kurtschindler.net/post/urlrewritingnet-performance-issues) so I've commented out all the rules and the performance issues have just vanished. I've not tried the alternative approach mentioned in the Kurt's blog entry, the redirects are historical and so could be ditched, but I wanted to post the cause / solution here in case it helps anyone else.
v4.7.2 Serious Performance Problem
I have a site set up using Umbraco v4.7.2 and the following packages:
Try the following:
1) Download the debug symbols from Codeplex for Umbaco and dump them into your /bin folder.
2) Begin a performance analysis with Visual Studio (if you have Pro or Ultimate edition, I think).
The performance analysis shows you exactly which thread is causing your lockup, and when you drill down into it, which methods are being called as part of the render process.
Best,
Benjamin
Hi Benjamin,
I don't have Pro or Ultimate, just Visual Studio Express, but I will go looking for the debug symbols now.
Many thanks,
Matt
Ah. In which case I'm gonna shoot round to venue now - gimme 20 minutes :-)
Adding debug symbols on their own will slow first load of the site, cause it has to match symbols to DLLs, so only do it if you plan on walking through the compiled Umbraco DLLs anyway.
See you in a tick,
B
Sorry I'm not at Code Garden, would take more than a tick to shoot round!
Based on your comment above, I'll hold of on the debug symbols (not 100% sure what I was looking for anyway)
Thanks,
Matt
Oh no! They might kill 4.7.2 too because it is too slow! Get ready for version 3.0.
Hi. As the first step I would try to view the page with "?umbDebugShowTrace=1" and inspect the timings to find out what stage of the whole page's lifecycle takes so long.
BTW, high CPU load itself is not always a bad thing as long as meanwhile the application itself keeps running fast (however, as I got it it's not the case here) - on the contrary too low CPU load can often point to some serious problems like excessive I/O, deadlocks, etc.
Thanks Rodion,
I had tried the debug trace but it didn't show any part of the page as being slow and I didn't recognise the very obvious significance of this (That Umbraco wasn't taking up the time) until I was pointed to the solution to the problem from outside of this forum (Many thanks to Brendan Rice for pointing me in the right direction).
The site had a whole stack of URL redirect rules and the performance issue was with the URL redirect module not with the Umbraco site (http://blog.kurtschindler.net/post/urlrewritingnet-performance-issues) so I've commented out all the rules and the performance issues have just vanished. I've not tried the alternative approach mentioned in the Kurt's blog entry, the redirects are historical and so could be ditched, but I wanted to post the cause / solution here in case it helps anyone else.
Matt
is working on a reply...