Content pages w/datatype using TinyMCE v3 wysiwyg slow to load & save on editing
Note: Doug Robar, who identified this problem while consulting for our installation, suggested I post this as a comment and once confirmed at later escalation as a bug. I'm a project manager, not a developer, posting this. However the posting below was written by developers:
A summary from our developer, Rob Mayfield
Umbraco 4.7.1
Architecture: Win2008 server – 8gb memory – 4 Zeon 2.27Ghz processors service pack 1 – 64 bit OS
IIS is the standard one with Windows 2008 which is version 7.5.7600.16385
SQL Server 2008 R2 on the local machine (same as Umbraco).
Using a dedicated application pool with Integrated pipeline Mode.
Umbraco 4.7.1 using old schema. Recompiled using Visual Studio 10 for debug and slight mod to library.aspx which is required for cross domain linking (4.0 – 4.7 did not resolve the domains properly until NiceUrlWithDomain was added. So I added a routine to handle the problem which was a slight tweak to NiceUrlFullPath). In 4.7.1 my routine just calls NiceUrlWithDomain from XSLTs and my added .Net Controls.
The front end has no problems and is very fast (1 -2 second response with little CPU usage - 5%).
On the backend the only slow piece is loading and saving and edit of content pages. The editing/saving of Document types, templates, Macros, XSLTs and the rest of the back end are as fast or faster than the 4.0 Umbraco server instance (which is on a win2003 server with 4 processors 8 gigs memory). Only Content pages containing the TinyMCE editor (datatype using TinyMCE v3 wysiwyg) are slow to load and save on editing. But on some content pages there may be up to 10 TinyMCE doc types (Richtext editor or TinyMCE Small Size or a few other with different button and size). (Images of testing appear below Doug Robar's analysis)
Response from Doug Robar:
I have confirmed the problem is with TinyMCE and is not unique to your installation. I was able to reproduce the problem on my machine with a fresh 4.7.1 installation. The times were not as exaggerated as for you but were nonetheless unmistakable.
I was able to further isolate the cause (though not yet the exact code in umbraco) and have a workaround that will help a lot, though not fully remove the issue.
The problem has to do with using stylesheets in your various TinyMCE datatypes. If you have no stylesheets selected in the datatype you'll get extremely quick performance. If you add only one you'll get most of the speed benefit as long as the loaded stylesheet isn't very big (as is typical for use in the RTE).
I've tested this on your staging site by creating one custom datatype, one docType, and one unpublished content page. All are named "_djRobar" so they are easy to find and delete. I left them for now so you can test them yourself in isolation without affecting anything in the rest of the site.
Here's what I found for timings opening a content page of doctype _djRobar with 5 of my _djRobar (TinyMCE) datatypes. The only difference is what stylesheets are ticked in the datatype.
editContent.aspx response with 5 RTE's
0.4 seconds no stylesheets selected in datatype
2.8 seconds umbraco_rt.css selected
38 seconds global.css selected
38 seconds global.css and surgery.css selected
40 seconds global.css, and surgery.css and umbraco_rt.css selected
The workaround, then, is to create a custom stylesheet that is used only within your datatypes that has as little as possible in it. You should hopefully get to ~5-10 second page loads in the admin even on your big doctypes.
I'll also note that the editDataType.aspx is slow when opening any TinyMCE-based datatype and this seems to be related to the total number of stylesheets in the settings section. It is made worse by having a lot of css in the files. This can be improved by deleting outdated css files from umbraco.
From our Developer - Detail:
On one of our site which is a test implementation called Model Home I used the ‘About US’ page as an example for referencing a very slow content editing page. The load times are about 45 - 50 seconds. The publish times are about the same as load times.
Creation times (right click - select Create - enter name and select Doc Type - click create) for content using the ‘Surgery Level 1’ doc type is 1 second. This is without Save or Publish. If I Save or Publish the time is about the same 45 -50 secs. This is also true of any Doc Type which contains a TinyMCE editor.
I did a test where I removed the TinyMCE’s on a content page (made a copy of ‘Surgery Level 1’ doc type (has 39 properties of which 9 are Tiny MCE properties) ) and replaced the 9 TinyMCE Data Types with Textbox Multiple (new doc type of ‘Surgery Level 1 No Tiny’ doc type). Editing a page created with the new doc type of ‘Surgery Level 1 No Tiny’, the page loaded in 2 -3 three seconds and saved or published in about 3 seconds. As I added back each TinyMCE, it added 4 -5 seconds of both display and save time. The content was about the same between the ‘About Us’ using the ‘Surgery Level 1’ Doc Type and the ‘About Us No Tiny’ page using the ‘Surgery Level 1 No Tiny’ doc type.
If I edit a Document type of one of the offending page (which is a ‘Surgery Level 1’ doc type) it takes about 5 seconds to load (%5 CPU usage) and 6 seconds to save (8% CPU usage). The save and load times of editing the doc type where the TinyMCE’s are replaced with Textbox Multiple (‘Surgery Level 1 No Tiny’) are the same as the TinyMCE doc type editing. So the editing of doc types are no different and equivalent to the Umbraco 4.0 implementation.
See CPU usage in image below
The CPU times for the offending (with TinyMCE) on save or load are as follows: CPU 1 90% usages. CPU 2,3,4 50% usage. Memory usage does not change much. SQL Server usage is only a small part of the usage 10% and only for 2-5 seconds. Most is IIS (80-90%) and lasts for the full duration of the publish/load 45-50 seconds). System usage is low 5%.
I decided to see if it was the server so I load the DB down to a local Windows 2003 server, installed Umbraco 4.7.1 and ran the same tests. The results were the same taking 40 - 50 seconds on the test page. I then move the Umbraco back to 4.7.0 and the times were faster by about 10 seconds (35 seconds to load/publish). Again Tiny was the only culprit as when I replaced tiny with Textbox Multiple the speeds were blazingly fast on save and load.
On my local machine with Firefox 9.0.1 the CPU spiked at 50% for about 1 second at the end of the publish/load reflecting loading the content into the browser. The memory show no change.
For comparison, on the production site (Umbraco 4.0) the publish/load time where about 15 seconds so the load save times caused by Tiny are about 3 times longer on 4.7.1 and 2.5 times longer on 4.7.
Most of the document types where built before the ability to have parent/child on doc types.
As to you last email about upgrading and Tiny being out of whack here is what I did.
Umbraco 4.0.3 was an upgrade from 3.?? (Can’t remember which sub version). I then upgraded to 4.5.2 using the instructions in 4.5.2 (copy in build and run install). I then upgraded to 4.7 using the same methodology. Then to 4.7.1. I think you may be right about Tiny being out of whack, maybe the wrong version, particularly since 4.7 runs 20% faster than 4.7.1. This seems to point to either a bug or some of the Tiny stuff missing or incorrect version. Since the hit is almost total on the server side it does not appear to be a Javascript issue. In fact Firebug just reports waiting on editContent.aspx for 95% of the 40 - 50 seconds of time.
Incidentally I just edited the Data Type (In Developer section) of Richtext editor and it took about 20 seconds to load but only 1 second to save. So maybe some logic related to Tiny in the backend since other Datatypes loaded in a couple of seconds.
Cheers,
Rob
Image represents a publish of About Us page using ‘Surgery Level 1’ which contains 9 TinyMCE boxes.
Just an update, I've downloaded all the website files from my shared hosting and am running on local IIS7 (but with the same DB on shared hosting) and I can access content with an RTE without problem.
My developer suggested that my post was a bit voluminnous. He suggested posting a more simplified description. Thus
Basically, for each instance of Tiny on a given document type, Umbraco loads the same style sheet, ie CSS repetitively, over and over. In our case, some of our forms have 8-10 instances of of Tiny-based fields. Until we dramatically slimmed down the CSS files that were reloaded serially, we had a major problem. He and (I think Doug) believes that the CSS should be loaded once and cached for the entire document type. In the image below, there are 10 tabs, each w/a Tiny field.
The problem with that, is that you ma have your own custom RTE datatypes using different stylesheets. Therefore the logic would be to search through the document for unique RTEs, load them X times for each RTE type, and cache accordingly. Will look to see if it's a quick patch.
But in my instance I'm using the standard RTE "once" on the document linked to an Editor stylesheet with a small number of styles in it. It can take anywhere upto 3 minutes to load the page.
Content pages w/datatype using TinyMCE v3 wysiwyg slow to load & save on editing
Note: Doug Robar, who identified this problem while consulting for our installation, suggested I post this as a comment and once confirmed at later escalation as a bug. I'm a project manager, not a developer, posting this. However the posting below was written by developers:
A summary from our developer, Rob Mayfield
Umbraco 4.7.1 using old schema. Recompiled using Visual Studio 10 for debug and slight mod to library.aspx which is required for cross domain linking (4.0 – 4.7 did not resolve the domains properly until NiceUrlWithDomain was added. So I added a routine to handle the problem which was a slight tweak to NiceUrlFullPath). In 4.7.1 my routine just calls NiceUrlWithDomain from XSLTs and my added .Net Controls.
The front end has no problems and is very fast (1 -2 second response with little CPU usage - 5%).
On the backend the only slow piece is loading and saving and edit of content pages. The editing/saving of Document types, templates, Macros, XSLTs and the rest of the back end are as fast or faster than the 4.0 Umbraco server instance (which is on a win2003 server with 4 processors 8 gigs memory). Only Content pages containing the TinyMCE editor (datatype using TinyMCE v3 wysiwyg) are slow to load and save on editing. But on some content pages there may be up to 10 TinyMCE doc types (Richtext editor or TinyMCE Small Size or a few other with different button and size). (Images of testing appear below Doug Robar's analysis)
Response from Doug Robar:
I have confirmed the problem is with TinyMCE and is not unique to your installation. I was able to reproduce the problem on my machine with a fresh 4.7.1 installation. The times were not as exaggerated as for you but were nonetheless unmistakable.
I was able to further isolate the cause (though not yet the exact code in umbraco) and have a workaround that will help a lot, though not fully remove the issue.
The problem has to do with using stylesheets in your various TinyMCE datatypes. If you have no stylesheets selected in the datatype you'll get extremely quick performance. If you add only one you'll get most of the speed benefit as long as the loaded stylesheet isn't very big (as is typical for use in the RTE).
I've tested this on your staging site by creating one custom datatype, one docType, and one unpublished content page. All are named "_djRobar" so they are easy to find and delete. I left them for now so you can test them yourself in isolation without affecting anything in the rest of the site.
Here's what I found for timings opening a content page of doctype _djRobar with 5 of my _djRobar (TinyMCE) datatypes. The only difference is what stylesheets are ticked in the datatype.
editContent.aspx response with 5 RTE's
0.4 seconds no stylesheets selected in datatype
2.8 seconds umbraco_rt.css selected
38 seconds global.css selected
38 seconds global.css and surgery.css selected
40 seconds global.css, and surgery.css and umbraco_rt.css selected
The workaround, then, is to create a custom stylesheet that is used only within your datatypes that has as little as possible in it. You should hopefully get to ~5-10 second page loads in the admin even on your big doctypes.
I'll also note that the editDataType.aspx is slow when opening any TinyMCE-based datatype and this seems to be related to the total number of stylesheets in the settings section. It is made worse by having a lot of css in the files. This can be improved by deleting outdated css files from umbraco.
From our Developer - Detail:
On one of our site which is a test implementation called Model Home I used the ‘About US’ page as an example for referencing a very slow content editing page. The load times are about 45 - 50 seconds. The publish times are about the same as load times.
Creation times (right click - select Create - enter name and select Doc Type - click create) for content using the ‘Surgery Level 1’ doc type is 1 second. This is without Save or Publish. If I Save or Publish the time is about the same 45 -50 secs. This is also true of any Doc Type which contains a TinyMCE editor.
I did a test where I removed the TinyMCE’s on a content page (made a copy of ‘Surgery Level 1’ doc type (has 39 properties of which 9 are Tiny MCE properties) ) and replaced the 9 TinyMCE Data Types with Textbox Multiple (new doc type of ‘Surgery Level 1 No Tiny’ doc type). Editing a page created with the new doc type of ‘Surgery Level 1 No Tiny’, the page loaded in 2 -3 three seconds and saved or published in about 3 seconds. As I added back each TinyMCE, it added 4 -5 seconds of both display and save time. The content was about the same between the ‘About Us’ using the ‘Surgery Level 1’ Doc Type and the ‘About Us No Tiny’ page using the ‘Surgery Level 1 No Tiny’ doc type.
If I edit a Document type of one of the offending page (which is a ‘Surgery Level 1’ doc type) it takes about 5 seconds to load (%5 CPU usage) and 6 seconds to save (8% CPU usage). The save and load times of editing the doc type where the TinyMCE’s are replaced with Textbox Multiple (‘Surgery Level 1 No Tiny’) are the same as the TinyMCE doc type editing. So the editing of doc types are no different and equivalent to the Umbraco 4.0 implementation.
See CPU usage in image below
The CPU times for the offending (with TinyMCE) on save or load are as follows: CPU 1 90% usages. CPU 2,3,4 50% usage. Memory usage does not change much. SQL Server usage is only a small part of the usage 10% and only for 2-5 seconds. Most is IIS (80-90%) and lasts for the full duration of the publish/load 45-50 seconds). System usage is low 5%.
I decided to see if it was the server so I load the DB down to a local Windows 2003 server, installed Umbraco 4.7.1 and ran the same tests. The results were the same taking 40 - 50 seconds on the test page. I then move the Umbraco back to 4.7.0 and the times were faster by about 10 seconds (35 seconds to load/publish). Again Tiny was the only culprit as when I replaced tiny with Textbox Multiple the speeds were blazingly fast on save and load.
On my local machine with Firefox 9.0.1 the CPU spiked at 50% for about 1 second at the end of the publish/load reflecting loading the content into the browser. The memory show no change.
For comparison, on the production site (Umbraco 4.0) the publish/load time where about 15 seconds so the load save times caused by Tiny are about 3 times longer on 4.7.1 and 2.5 times longer on 4.7.
Most of the document types where built before the ability to have parent/child on doc types.
As to you last email about upgrading and Tiny being out of whack here is what I did.
Umbraco 4.0.3 was an upgrade from 3.?? (Can’t remember which sub version). I then upgraded to 4.5.2 using the instructions in 4.5.2 (copy in build and run install). I then upgraded to 4.7 using the same methodology. Then to 4.7.1. I think you may be right about Tiny being out of whack, maybe the wrong version, particularly since 4.7 runs 20% faster than 4.7.1. This seems to point to either a bug or some of the Tiny stuff missing or incorrect version. Since the hit is almost total on the server side it does not appear to be a Javascript issue. In fact Firebug just reports waiting on editContent.aspx for 95% of the 40 - 50 seconds of time.
Incidentally I just edited the Data Type (In Developer section) of Richtext editor and it took about 20 seconds to load but only 1 second to save. So maybe some logic related to Tiny in the backend since other Datatypes loaded in a couple of seconds.
Cheers,
Rob
Image represents a publish of About Us page using ‘Surgery Level 1’ which contains 9 TinyMCE boxes.
Great information! Thanks a lot for sharing!
I am also having this issue on a number of my Umbraco installations. although removing the stylesheets does not solve the issue for me.
Just an update, I've downloaded all the website files from my shared hosting and am running on local IIS7 (but with the same DB on shared hosting) and I can access content with an RTE without problem.
My developer suggested that my post was a bit voluminnous. He suggested posting a more simplified description. Thus
Basically, for each instance of Tiny on a given document type, Umbraco loads the same style sheet, ie CSS repetitively, over and over. In our case, some of our forms have 8-10 instances of of Tiny-based fields. Until we dramatically slimmed down the CSS files that were reloaded serially, we had a major problem. He and (I think Doug) believes that the CSS should be loaded once and cached for the entire document type. In the image below, there are 10 tabs, each w/a Tiny field.
This was a duplicate post so I removed the content. There seems to be no way to delete it.
The problem with that, is that you ma have your own custom RTE datatypes using different stylesheets. Therefore the logic would be to search through the document for unique RTEs, load them X times for each RTE type, and cache accordingly. Will look to see if it's a quick patch.
But in my instance I'm using the standard RTE "once" on the document linked to an Editor stylesheet with a small number of styles in it. It can take anywhere upto 3 minutes to load the page.
is working on a reply...