Yesterday I got a mail from a host (Surftown) of one of my shared hosted sites, telling me that my site uses too many resources, especially the cpu load is too high, so my site was isolated and granted only limited resources. Bummer.
On a good day the site is visited by 50 users, so it's not heavily loaded, but I suspect that the issues arise when editing the site from the Umbraco backend - in the isolated environment this is where I get "Service Unavailable", probably due to resource limits on the server.
Are there any obvious things to check/setup on my site to limit the cpu load/memory consumption ?
What version of umbraco you using? I have seen this before in xslt doing GetXmlNodeById when node does not exist can't remember which version. Check you xslts you may have other issues that are causing the high load, in the past for me its always been xslt's which ends up giving service unavailable.
Well, first of all have you had a look at the trace (add umbDebugShowTrace=true to the querystring) on multiple pages on your site? Especially pages for which you are using a usercontrol or your own xslt extension might be of interest. The most interesting delays can be found after you touch the web.config. None of the macro's are cached then, so you get the heaviest load.
If you're only having problems in the backoffice (saving content etc.) it might be worth checking to see if any of your eventhandlers can be refactored.
I'm curious about the results of the trace, can you also say something about the amount of customization you've done?
Thanks Sebastian - I did a great number af xslt customization, but I'm not too worried about that. It's mainly in the backend, but checking out the eventhandlers is an excellent input.
How would xml caching or other types of caching have an impact?
The static HTML is cached for most items I suppose, so that would in fact NOT drive the CPU load up. So testing it before caching is in effect might result in some interesting points to dig further.
In your event handlers, try to avoid hitting the database as much as you can, every time you loop through something like a set of Documents, you will pull lot's of data from the database. I had similar issues and refactored so that I only would hit the DB if it was absolutely necessary.
Another possibility is if your site is using an old version of ImageGen. Be sure to get the update for ImageGen 2.2 from http://our.umbraco.org/projects/imagegen, which fixes an important caching bug that could result in more cpu use than necessary.
You can check the version of ImageGen on your site at http://example.com/umbraco/imagegen.ashx?version (where example.com would be replaced with your site's domain). If the version is 2.0.1 you definitely want the update.
Certainly the umbraco admin interface uses more resources than the website itself, since it is hitting the database all the time, which uses cpu cycles. Not much to do there, except maybe add some indexes. You can find various forum posts and codeplex issues discussing these in more detail.
If you use .net macros or your own xslt extensions, be sure to use the node factory whenever possible as that is much faster and uses fewer cpu/database cycles. Dirk has a nice blog post explaining when, why, and how to use the node factory at http://www.netaddicts.be/articles/document-api-vs-nodefactory.aspx
Lastly... this may simply be an overly-zealous shared host who is really expecting you to have static pages and use almost no resources on their maxed-out servers? This is a potential difficulty with shared hosting providers and the option is sometimes to upgrade your service level, find another host, or go to a VPS or some other hosting alternative. I finally left an otherwise excellent shared hosting provider for this very reason. At the time I thought it might have been a waste of money but I've had NO problems since going to VPS and hosting all my sites there. Ultimately it costs less for hosting and I spend less time administering the sites.
My thoughts exactly Douglas, having remote desktop access to my server is so much easier than going through silly plesk (etc.) control panels. Having access to Windows and all of the tools that I'm familiar with saves a lot of time trying to do weird debug sessions having to upload the bin folder several times.
Of course, as always: "with great power comes great responsibility".
Any obvious actions to lower cpu load?
Yesterday I got a mail from a host (Surftown) of one of my shared hosted sites, telling me that my site uses too many resources, especially the cpu load is too high, so my site was isolated and granted only limited resources. Bummer.
On a good day the site is visited by 50 users, so it's not heavily loaded, but I suspect that the issues arise when editing the site from the Umbraco backend - in the isolated environment this is where I get "Service Unavailable", probably due to resource limits on the server.
Are there any obvious things to check/setup on my site to limit the cpu load/memory consumption ?
Thanks
>Tommy
Tommy,
What version of umbraco you using? I have seen this before in xslt doing GetXmlNodeById when node does not exist can't remember which version. Check you xslts you may have other issues that are causing the high load, in the past for me its always been xslt's which ends up giving service unavailable.
Regards
Ismail
Hi Ismail, thanks for the advice - I'll consider my xslt's. But often I get the "Service unavailable" when saving content etc.
The site is using Umbraco 4.0.3
>Tommy
Well, first of all have you had a look at the trace (add umbDebugShowTrace=true to the querystring) on multiple pages on your site? Especially pages for which you are using a usercontrol or your own xslt extension might be of interest. The most interesting delays can be found after you touch the web.config. None of the macro's are cached then, so you get the heaviest load.
If you're only having problems in the backoffice (saving content etc.) it might be worth checking to see if any of your eventhandlers can be refactored.
I'm curious about the results of the trace, can you also say something about the amount of customization you've done?
Thanks Sebastian - I did a great number af xslt customization, but I'm not too worried about that. It's mainly in the backend, but checking out the eventhandlers is an excellent input.
How would xml caching or other types of caching have an impact?
The static HTML is cached for most items I suppose, so that would in fact NOT drive the CPU load up. So testing it before caching is in effect might result in some interesting points to dig further.
In your event handlers, try to avoid hitting the database as much as you can, every time you loop through something like a set of Documents, you will pull lot's of data from the database. I had similar issues and refactored so that I only would hit the DB if it was absolutely necessary.
xmlcaching is currently turned off in umbraco config due to some issues earlier with security. I'll definitely inspect my eventhandlers.
Another possibility is if your site is using an old version of ImageGen. Be sure to get the update for ImageGen 2.2 from http://our.umbraco.org/projects/imagegen, which fixes an important caching bug that could result in more cpu use than necessary.
You can check the version of ImageGen on your site at http://example.com/umbraco/imagegen.ashx?version (where example.com would be replaced with your site's domain). If the version is 2.0.1 you definitely want the update.
Certainly the umbraco admin interface uses more resources than the website itself, since it is hitting the database all the time, which uses cpu cycles. Not much to do there, except maybe add some indexes. You can find various forum posts and codeplex issues discussing these in more detail.
If you use .net macros or your own xslt extensions, be sure to use the node factory whenever possible as that is much faster and uses fewer cpu/database cycles. Dirk has a nice blog post explaining when, why, and how to use the node factory at http://www.netaddicts.be/articles/document-api-vs-nodefactory.aspx
Lastly... this may simply be an overly-zealous shared host who is really expecting you to have static pages and use almost no resources on their maxed-out servers? This is a potential difficulty with shared hosting providers and the option is sometimes to upgrade your service level, find another host, or go to a VPS or some other hosting alternative. I finally left an otherwise excellent shared hosting provider for this very reason. At the time I thought it might have been a waste of money but I've had NO problems since going to VPS and hosting all my sites there. Ultimately it costs less for hosting and I spend less time administering the sites.
Let us know what you find out.
cheers,
doug.
My thoughts exactly Douglas, having remote desktop access to my server is so much easier than going through silly plesk (etc.) control panels. Having access to Windows and all of the tools that I'm familiar with saves a lot of time trying to do weird debug sessions having to upload the bin folder several times.
Of course, as always: "with great power comes great responsibility".
Awesome guys, I've got enough to start some investigations...
>Tommy
btw, ImageGen is version 2.2.1.38932
is working on a reply...