Having an issue with umbraco spiking up the w3wp process to 100% when I click on a content node in the back-end. Every time I click on an ode, the w3wp process shoots-up for a few seconds. It takes about 5+ seconds to load a node. There aren't many custom fields on the document type the nodes use, so I can't see what's causing the issue.
On the front-end, as I navigate through the pages, the process jumps from 40-50% for each page I click. I'm wondering if this could be the XSLT on the front-end, so I'm going to play around with caching, etc. Still not sure what's going on with the back-end though.
Has anyone else run into this issue? I'm not sure how to tackle finding out what's causing the spike.
There is a new custom data type, which is just a Rich Text Editor I created this morning. The site, however, was doing this before I added the RTE. Here is my DocType setup for my content node:
BasePage
Content [rte] Title [string] Alternate Language Page [content picker] Link Text [string] Hide in Main Nav [bool] Hide in Sub Nav [bool] Hide in Site Map [bool] Page_ID (used in XSL to apply a specific CSS class to some pages)
Interior Page (extends BasePage)
No properties for now, but did it this way so that if there are common properties between FR and EN interior pages added at a later time they can go here.
Interior Page EN (extends Interior Page)
Side Image (media picker) Side Content (RTE - My new custom data type that is just the TinyMCE editor with no extended properties. I did this so I could give it a custom width that differed from the main content)
So I modified my doc types and changed any field that was using TinyMCE (rich text editor) to use Textbox Multiple. The CPU no longer spiles to 100% when I click on a node in the content admin. The node loads instantly...
So, the question is, what is happening on the server that would cause this? For the most part TinyMCE is client-heavy, and I'd expect that the stored data type in SQL for both TinyMCE and Textbox Multiple would be text. I can see some logic to show/hide icon sets based on user type, but even then, that shouldn't casue a 3-4s lag for loading the node and a 100% CPU spike.
Update: Found a solution, but can't explain exactly why the problem occurred.
Turns out a specific style in our editor stylesheet was causing the issue.
We're using a font from http://new.myfonts.com/ for titles and I there was a @font-face style in the editor that contained the actual font information within the stylesheet. This not only jacked up the size of the sheet by 40k but was causing whatever code Umbraco/.NET uses to process the stylesheets to go very slow and spike the CPU up. Since the @font-face style was only used for Firefox and Chrome (and our users will be primarily using IE to edit) we've moved that style out of the editor stylesheet and into one that is only loaded in Canvas/Published pages.
I noticed even without @font-face that a larger CSS file will still spike the CPU up fairly high, anywhere from 20-40% when a content node with a RTE is selected. Does anyone have any idea why this is? What code could be running against a fairly small CSS file that's causing the CPU to jump that high?
w3wp.exe spikes to 100% in admin and 50% on front-end
Hi All,
Having an issue with umbraco spiking up the w3wp process to 100% when I click on a content node in the back-end. Every time I click on an ode, the w3wp process shoots-up for a few seconds. It takes about 5+ seconds to load a node. There aren't many custom fields on the document type the nodes use, so I can't see what's causing the issue.
On the front-end, as I navigate through the pages, the process jumps from 40-50% for each page I click. I'm wondering if this could be the XSLT on the front-end, so I'm going to play around with caching, etc. Still not sure what's going on with the back-end though.
Has anyone else run into this issue? I'm not sure how to tackle finding out what's causing the spike.
Thanks,
Jay
what version of umbraco are you using and does the node have a custom datatype?
regards
Isamil
Hi Ismail,
I'm using 4.6.1. Assembly ver 1.0.4029.25836
There is a new custom data type, which is just a Rich Text Editor I created this morning. The site, however, was doing this before I added the RTE. Here is my DocType setup for my content node:
BasePage
Content [rte]
Title [string]
Alternate Language Page [content picker]
Link Text [string]
Hide in Main Nav [bool]
Hide in Sub Nav [bool]
Hide in Site Map [bool]
Page_ID (used in XSL to apply a specific CSS class to some pages)
Interior Page (extends BasePage)
No properties for now, but did it this way so that if there are common properties between FR and EN interior pages added at a later time they can go here.
Interior Page EN (extends Interior Page)
Side Image (media picker)
Side Content (RTE - My new custom data type that is just the TinyMCE editor with no extended properties. I did this so I could give it a custom width that differed from the main content)
I don't know if any of this info helps though. :)
Thanks,
Jay
Update:
So I modified my doc types and changed any field that was using TinyMCE (rich text editor) to use Textbox Multiple. The CPU no longer spiles to 100% when I click on a node in the content admin. The node loads instantly...
So, the question is, what is happening on the server that would cause this? For the most part TinyMCE is client-heavy, and I'd expect that the stored data type in SQL for both TinyMCE and Textbox Multiple would be text. I can see some logic to show/hide icon sets based on user type, but even then, that shouldn't casue a 3-4s lag for loading the node and a 100% CPU spike.
Any thoughts?
Update: Found a solution, but can't explain exactly why the problem occurred.
Turns out a specific style in our editor stylesheet was causing the issue.
We're using a font from http://new.myfonts.com/ for titles and I there was a @font-face style in the editor that contained the actual font information within the stylesheet. This not only jacked up the size of the sheet by 40k but was causing whatever code Umbraco/.NET uses to process the stylesheets to go very slow and spike the CPU up. Since the @font-face style was only used for Firefox and Chrome (and our users will be primarily using IE to edit) we've moved that style out of the editor stylesheet and into one that is only loaded in Canvas/Published pages.
I noticed even without @font-face that a larger CSS file will still spike the CPU up fairly high, anywhere from 20-40% when a content node with a RTE is selected. Does anyone have any idea why this is? What code could be running against a fairly small CSS file that's causing the CPU to jump that high?
Thanks,
Jay
hey guys do you use fonts to make-up your photos? I use the ones form here Free fonts
is working on a reply...