We are taking a major site live and have trying to figure out why the backoffice performance of the CMS was so horrid. By horrid, I'm talking about taking sometimes 20-30 seconds or more for a page to open on the CMS running on very stout servers.
In an effort to troubleshoot I started running profiler on the SQL calls.
The #1 thing I found slowing down the loading was 16 calls being made to: select filename, content from cmsStylesheet where nodeid = #### (NOTE: THE NODE ID WAS THE SAME EACH TIME).
First and foremost, I'm not sure why this would even be needed, as the stylesheet isn't even used when you're editing the page in the CMS to my knowledge. Additionally, the stylesheet is in the physical filesystem.
Second, even if it is needed, is it really necessary to grab the data 16 times? It would be much more efficient if the system had some logic to see if it has already gotten the needed data from the database instead of querying the same thing over and over again. What causes the bottleneck is that every time it calls this query it transmits all the data in the CSS file. We have a decent size CSS file, and this was REALLY slowing things down. I did find a quick fix that helped a lot as far as SQL performance went--I simply deleted all the CSS data out of the database in umbraco and left the physical file on the file system. Boom, SQL performance increased by 11 seconds.
It seems that there are a lot of queries that get made many many times just for loading up one page in the system. Another specific example is:
select id from umbracoNode where ParentID = #### order by sortOrder
This EXACT query gets run 96 times when I load a page LOL. Thankfully it's very quick, but still, why!?
This sneaks up un you, because you'll add more and more styles to be avaialable in the editor as a site matures, and every style takes 4 db calls. Then you get it local to work on it, and it seems fast enough...but a remote db can mean a second elapsed per call, four calls a style, 10 styles an editor, two editors per doctype, and you're waiting a long time for that content node to show in the backend. There were issues in the tracker, but I can't find them anymore. Must be fixed in 5
Dis-associate the stylesheet from the richtext editor datatype, and you'll be able to work in the Content tree.
General horrible backoffice performance and a few specific findings
Hey All,
We are taking a major site live and have trying to figure out why the backoffice performance of the CMS was so horrid. By horrid, I'm talking about taking sometimes 20-30 seconds or more for a page to open on the CMS running on very stout servers.
In an effort to troubleshoot I started running profiler on the SQL calls.
The #1 thing I found slowing down the loading was 16 calls being made to: select filename, content from cmsStylesheet where nodeid = #### (NOTE: THE NODE ID WAS THE SAME EACH TIME).
First and foremost, I'm not sure why this would even be needed, as the stylesheet isn't even used when you're editing the page in the CMS to my knowledge. Additionally, the stylesheet is in the physical filesystem.
Second, even if it is needed, is it really necessary to grab the data 16 times? It would be much more efficient if the system had some logic to see if it has already gotten the needed data from the database instead of querying the same thing over and over again. What causes the bottleneck is that every time it calls this query it transmits all the data in the CSS file. We have a decent size CSS file, and this was REALLY slowing things down. I did find a quick fix that helped a lot as far as SQL performance went--I simply deleted all the CSS data out of the database in umbraco and left the physical file on the file system. Boom, SQL performance increased by 11 seconds.
It seems that there are a lot of queries that get made many many times just for loading up one page in the system. Another specific example is:
select id from umbracoNode where ParentID = #### order by sortOrder
This EXACT query gets run 96 times when I load a page LOL. Thankfully it's very quick, but still, why!?
After doing a little more digging, I found that it's the CSS file that is associated with the Rich Text editor in the datatypes section.
It apparantly pulls all the css text from the database for every rich text editor you have on the page, even though they're all the same data type.
This sneaks up un you, because you'll add more and more styles to be avaialable in the editor as a site matures, and every style takes 4 db calls. Then you get it local to work on it, and it seems fast enough...but a remote db can mean a second elapsed per call, four calls a style, 10 styles an editor, two editors per doctype, and you're waiting a long time for that content node to show in the backend. There were issues in the tracker, but I can't find them anymore. Must be fixed in 5
Dis-associate the stylesheet from the richtext editor datatype, and you'll be able to work in the Content tree.
is working on a reply...