I'm creating a new topic for this as the other one focused entirely on the front-end controls.
The CMS itself is fine until people start publishing, then it slows down a lot. It can take 40-60 seconds to publish one of the more complex document types. The CPU usage appears to be close to 100% most of the time (it's fine if I turn the site off in IIS)
Hmmm. Very strange. I've had a site with about 7000 nodes on a much less powerful laptop's virtual machine (Win2003 server, IIS6, SQLserver Express 2005) and though it wasn't "fast" it wasn't anything like what you're describing. On a real server it was wonderful.
So... a couple comments and some questions:
Remember that when content editors use the umbraco administration UI, the database is heavily involved. Some have reported quite un-optimized sql calls and lots of them. This can make the umbraco admin sluggish or slow, depending on your database setup. Note that umbraco's architecture is such that people visiting your website make no/few database hits so the 'frontend' performance and the 'backend' performance are not particularly related.
Tell us a bit more about your server setup. What OS and SQL version are you running? Is the database and iis both fighting for memory (or forcing each other to swap out to disk)? Any events in the event log?
Do you get the same kind of slowness when using different browsers or if you're on the server itself?
Does the slowness happen only on publish, or also when you click the 'save' icon? Is everything slow, or just some actions?
If you delete all the files in the /data/systemUmbracoIndexDontDelete folder and then visit the http://yoursite.com/umbraco/reindex.aspx page to re-create the search index for umbraco, does that help anything? (I'm just thinking that maybe the indexer is kind of confused and is having a hard time indexing when a page is published... deleting the index files will force it to create a fresh index and should resolve that issue)
I had almost the same issues with importing more than a 2000 nodes using UmbImport. I've spoken to a couple of guys who had a workarround. They advised me to set the settings XmlCacheEnabled and ContinouslyUpdateXmlDiskCache to false during the import, that is because the caching mechanism will slow down the process instead increasing it. That increased the import a lot. I think you need to play with these settings a bit. and see how the UI behaves and how fast the import goes.
One other thing that came to mind. Are you using events during the publish?
The site is running on Windows Server 2003 with service pack 2, SQL Server 2008 and IIS6.
Locally I run it on Vista/IIS7 and a remote instance of SQL Server 2008. I experience slowness locally too.
Event Viewer is clear.
Not everything is slow - navigating most of the site is reasonably swift, unless there is more than one person using it, then everything starts to slow down. It's the opening of larger documents that cause the greatest issues. There are several Ultimate Picker data types on these documents - I'm not sure how that affects performance.
Yes I am using events during publish! I use them to delete and recreate relationships using umbraco.cms.businesslogic.relation... The CMS was slow before this was added but it is probably adding to the process time.
XmlCacheEnabled and ContinouslyUpdateXmlDiskCache are both set to true.
Testing locally (SQL Server is on another box on the network) I have reindexed (which took about 2 hrs) and tested to see whether the bottle-neck is in the event handler code. The bulk of the time to publish is before breakpoints in the event handle code is hit. The event handlers themselves run in milliseconds.
I had similar problems with a slow UI, found out it was due to two member pickers at the document types I used the most. The ui was fast at first, before I imported x 000 members (duh). Preliminary solution now is using a numeric date type instead. A filtered member picker would be nice, or even a drop down list with possibilty to enter both the displayed strings as well as the data values.
CMS Slow, especially publishing
I'm creating a new topic for this as the other one focused entirely on the front-end controls.
The CMS itself is fine until people start publishing, then it slows down a lot. It can take 40-60 seconds to publish one of the more complex document types. The CPU usage appears to be close to 100% most of the time (it's fine if I turn the site off in IIS)
http://img14.imageshack.us/i/cpuusagey.jpg/
I think it is particularly bad when more than one person is using the CMS to create, publish and view items at the same time.
Any thoughts?
umbraco v 4.0.1 (Assembly version: 1.0.3373.718), 3hz processor, 2GB RAM, ~5000 nodes.
Hmmm. Very strange. I've had a site with about 7000 nodes on a much less powerful laptop's virtual machine (Win2003 server, IIS6, SQLserver Express 2005) and though it wasn't "fast" it wasn't anything like what you're describing. On a real server it was wonderful.
So... a couple comments and some questions:
Remember that when content editors use the umbraco administration UI, the database is heavily involved. Some have reported quite un-optimized sql calls and lots of them. This can make the umbraco admin sluggish or slow, depending on your database setup. Note that umbraco's architecture is such that people visiting your website make no/few database hits so the 'frontend' performance and the 'backend' performance are not particularly related.
Tell us a bit more about your server setup. What OS and SQL version are you running? Is the database and iis both fighting for memory (or forcing each other to swap out to disk)? Any events in the event log?
Do you get the same kind of slowness when using different browsers or if you're on the server itself?
Does the slowness happen only on publish, or also when you click the 'save' icon? Is everything slow, or just some actions?
If you delete all the files in the /data/systemUmbracoIndexDontDelete folder and then visit the http://yoursite.com/umbraco/reindex.aspx page to re-create the search index for umbraco, does that help anything? (I'm just thinking that maybe the indexer is kind of confused and is having a hard time indexing when a page is published... deleting the index files will force it to create a fresh index and should resolve that issue)
Anything else you can tell us about your setup?
cheers,
doug.
Hi Peter,
I had almost the same issues with importing more than a 2000 nodes using UmbImport. I've spoken to a couple of guys who had a workarround. They advised me to set the settings XmlCacheEnabled and ContinouslyUpdateXmlDiskCache to false during the import, that is because the caching mechanism will slow down the process instead increasing it. That increased the import a lot. I think you need to play with these settings a bit. and see how the UI behaves and how fast the import goes.
One other thing that came to mind. Are you using events during the publish?
Cheers,
Richard
Great reply thanks, Doug.
The site is running on Windows Server 2003 with service pack 2, SQL Server 2008 and IIS6.
Locally I run it on Vista/IIS7 and a remote instance of SQL Server 2008. I experience slowness locally too.
Event Viewer is clear.
Not everything is slow - navigating most of the site is reasonably swift, unless there is more than one person using it, then everything starts to slow down. It's the opening of larger documents that cause the greatest issues. There are several Ultimate Picker data types on these documents - I'm not sure how that affects performance.
I will look into the indexing, cheers.
Yes I am using events during publish! I use them to delete and recreate relationships using umbraco.cms.businesslogic.relation... The CMS was slow before this was added but it is probably adding to the process time.
XmlCacheEnabled and ContinouslyUpdateXmlDiskCache are both set to true.
Update:
Testing locally (SQL Server is on another box on the network) I have reindexed (which took about 2 hrs) and tested to see whether the bottle-neck is in the event handler code. The bulk of the time to publish is before breakpoints in the event handle code is hit. The event handlers themselves run in milliseconds.
I have tracked the slowness to the use of UltimatePicker as a CheckboxList - quite a few are used and there are many items in most of them.
Thanks for the responses :)
I had similar problems with a slow UI, found out it was due to two member pickers at the document types I used the most. The ui was fast at first, before I imported x 000 members (duh). Preliminary solution now is using a numeric date type instead. A filtered member picker would be nice, or even a drop down list with possibilty to enter both the displayed strings as well as the data values.
ah, http://umbracodatatypes.codeplex.com/
is working on a reply...