Is there a way to check what is causing the backend to respond in more than 30 seconds?
We've created a load balanced farm for an umbraco site, and the backend is extremely slow, is there a way to trace what is causing the long load times that you can think of?
Error removing node from umbraco index: 'System.IO.FileNotFoundException: Could not find file '\\brain52\WebSharedCont\Farm01\www.desingel.be\data\_systemUmbracoIndexDontDelete\_3gn.fnm'. File name: '\\brain52\WebSharedCont\Farm01\www.desingel.be\data\_systemUmbracoIndexDontDelete\_3gn.fnm'
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share) at Lucene.Net.Store.FSIndexInput.Descriptor..ctor(FSIndexInput enclosingInstance, FileInfo file, FileAccess mode) at Lucene.Net.Store.FSIndexInput..ctor(FileInfo path) at Lucene.Net.Store.FSDirectory.OpenInput(String name) at Lucene.Net.Index.FieldInfos..ctor(Directory d, String name) at Lucene.Net.Index.SegmentReader.Initialize(SegmentInfo si) at Lucene.Net.Index.SegmentReader.Get(Directory dir, SegmentInfo si, SegmentInfos sis, Boolean closeDir, Boolean ownDir) at Lucene.Net.Index.IndexReader.AnonymousClassWith.DoBody() at Lucene.Net.Store.Lock.With.Run() at Lucene.Net.Index.IndexReader.Open(Directory directory, Boolean closeDirectory) at Lucene.Net.Index.IndexReader.Open(String path) at umbraco.cms.businesslogic.index.Indexer.RemoveNode(Int32 Id)'
The server is a load balanced server with a sharedcontent folder, sql is on a different server on the same fysical machine (vmware), plenty of memory and disk space
not wanting to hijack the thread but I have a couple of installs that have recently become desperately slow on the back end. Public site performance is pretty good.
I am struggling to find the reason, some pages are taking up to 30 seconds to load. Firebug points at huge wait times for editContent.aspx. An example is here. Eek! Really appreciate any pointers on where to start looking. Macros? User Controls? System related? I noticed in SQL profiler that there are a lot of DB calls as the page loads (~2000) although DB is indexed well and performance looks OK. Certainly shouldn't cause a 20+ second hold up.
Have run /umbraco/reindex.aspx.
In the logs I get repeated "Error reading size data from media (not found): /media/..." errors being raised. There was content uploaded via Zip Uploader. I tried manually resaving each image (about 100 of them in folders nested up to three levels) but that hasn't stopped the errors. Could this be holding things up?
Any performance tips really welcome as feeling a bit lost getting to the bottom of this...
Thom, is it only on the content nodes? Once had a client who added about 100 styles into the style dropdown menu, and it caused the editContent page to load extremely slowly or timeout. That was in version 3 though, it may be able to handle that many now.
no load balancing. Setup is Windows 2008 Standard SP2. IIS7. SQL Server 2008 Enterprise (clustered). All on same LAN. Web server is Dual Xeon, 4GB memory, 32 bit. No sign of performance issues on web server or sql server.
We have no styles defined in the RTE.
Site has around 80 content nodes.
Media library performance seems pretty snappy.
I was thinking that this is going to be something really stupid that we've added in XSLT or a user control but even a node without any of those it's running slow. Very frustrating, my users are starting to get restless ;-)
in my case we have a site that is lightening fast on a localhost with local Db, but then incredibly slow (backend) when we migrated it tot he loadbalanced productionserver...
As mentioned, we're not loadbalanced on the webserver but I just got the offending site up and running on my workstation, using local SQL Server and those editContent.aspx calls are taking ~2 seconds rather than 20. Something wrong with production webserver or SQL Server, just need to figure out what.
Not really what I wanted to be doing with my Monday morning, going to be so relieved when I figure this out ;-)
We moved the affected sites to a newly built webserver in the end and the issue went away. Would have been good to have found the cause but needs must and had to get things running before the revolt started among our users.
Is there a way to check what is causing the backend to respond in more than 30 seconds?
We've created a load balanced farm for an umbraco site, and the backend is extremely slow, is there a way to trace what is causing the long load times that you can think of?
Thanks,
Rik
Hi Rik
Did you check the UmbracoLog table in the database?
Cheers,
Richard
I can spot some of these errors:
The server is a load balanced server with a sharedcontent folder, sql is on a different server on the same fysical machine (vmware), plenty of memory and disk space
I deleted all the files in the systemUmbracoIndexDontDelete folder and recreated the index using /umbraco/reindex.aspx
So far there isn't much difference
is it normal that all the files in this folder keep changing / being deleted ? i thought it was some sort of cache but the files never stay the same?
not wanting to hijack the thread but I have a couple of installs that have recently become desperately slow on the back end. Public site performance is pretty good.
I am struggling to find the reason, some pages are taking up to 30 seconds to load. Firebug points at huge wait times for editContent.aspx. An example is here. Eek! Really appreciate any pointers on where to start looking. Macros? User Controls? System related? I noticed in SQL profiler that there are a lot of DB calls as the page loads (~2000) although DB is indexed well and performance looks OK. Certainly shouldn't cause a 20+ second hold up.
Have run /umbraco/reindex.aspx.
In the logs I get repeated "Error reading size data from media (not found): /media/..." errors being raised. There was content uploaded via Zip Uploader. I tried manually resaving each image (about 100 of them in folders nested up to three levels) but that hasn't stopped the errors. Could this be holding things up?
Any performance tips really welcome as feeling a bit lost getting to the bottom of this...
Thom: are you also using a loadbalanced server?
Thom, is it only on the content nodes? Once had a client who added about 100 styles into the style dropdown menu, and it caused the editContent page to load extremely slowly or timeout. That was in version 3 though, it may be able to handle that many now.
Quick responses!
no load balancing. Setup is Windows 2008 Standard SP2. IIS7. SQL Server 2008 Enterprise (clustered). All on same LAN. Web server is Dual Xeon, 4GB memory, 32 bit. No sign of performance issues on web server or sql server.
We have no styles defined in the RTE.
Site has around 80 content nodes.
Media library performance seems pretty snappy.
I was thinking that this is going to be something really stupid that we've added in XSLT or a user control but even a node without any of those it's running slow. Very frustrating, my users are starting to get restless ;-)
About to make a copy of the site and will start removing third party data types and see if one of those is the cause...
in my case we have a site that is lightening fast on a localhost with local Db, but then incredibly slow (backend) when we migrated it tot he loadbalanced productionserver...
As mentioned, we're not loadbalanced on the webserver but I just got the offending site up and running on my workstation, using local SQL Server and those editContent.aspx calls are taking ~2 seconds rather than 20. Something wrong with production webserver or SQL Server, just need to figure out what.
Not really what I wanted to be doing with my Monday morning, going to be so relieved when I figure this out ;-)
We moved the affected sites to a newly built webserver in the end and the issue went away. Would have been good to have found the cause but needs must and had to get things running before the revolt started among our users.
is working on a reply...