One of our key customers is having performance issues with our Scheduler. They mainly manifest themselves by locking up the Scheduler and occasionally crashing the browser that it is open within.
We have investigated this and found that whenever the mouse is moved around within the Scheduler, the memory and CPU resources spike, often to 100%. This is not while dragging or anything. Though we have a lot of custom client code, it looks to be caused by client mouse events that are native to the Scheduler control.
Has anyone else experienced similar issues?
Is it possible to turn off some/all of the Schedulers client events?
Are there any recommended best practices surrounding this?
We have investigated this and found that whenever the mouse is moved around within the Scheduler, the memory and CPU resources spike, often to 100%. This is not while dragging or anything. Though we have a lot of custom client code, it looks to be caused by client mouse events that are native to the Scheduler control.
Has anyone else experienced similar issues?
Is it possible to turn off some/all of the Schedulers client events?
Are there any recommended best practices surrounding this?
6 Answers, 1 is accepted
0
Hi Jeff,
Which version of RadCotnrols for ASP.NET AJAX are you using? The appointment rendering in the old versions required a lot of physical memory and could probably cause such issues when hovered (though I didn't experience that myself). Check this blog post about the changes in the appointment rendering introduced in the latest version. Can you upgrade to it and see if that helps your issue?
Greetings,
Kamen Bundev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
Which version of RadCotnrols for ASP.NET AJAX are you using? The appointment rendering in the old versions required a lot of physical memory and could probably cause such issues when hovered (though I didn't experience that myself). Check this blog post about the changes in the appointment rendering introduced in the latest version. Can you upgrade to it and see if that helps your issue?
Greetings,
Kamen Bundev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
Jeff Nafe
Top achievements
Rank 1
Rank 1
answered on 18 Mar 2010, 01:46 PM
Hey Kamen-
We have recently upgraded to the 2010 Q1 version and we still see it. Though the scheduler is rendering faster, it's the CPU spike that occurs when moving the mouse over the scheduler that is causing the issues on some client machines.
I can reproduce this (on a much smaller scale) on some of your demos. For example if I go to http://demos.telerik.com/aspnet-ajax/scheduler/examples/outlook2007/defaultcs.aspx, my CPU Usage stays around 15%. If I start moving the mouse around, back and forth, on top of the Scheduler, it gets up to 35-40%. Obviously a bunch of client events are being raised. So, my main question is whether we have any control over what gets raised, is there any way to minimize the memory footprint, etc?
Thanks!
We have recently upgraded to the 2010 Q1 version and we still see it. Though the scheduler is rendering faster, it's the CPU spike that occurs when moving the mouse over the scheduler that is causing the issues on some client machines.
I can reproduce this (on a much smaller scale) on some of your demos. For example if I go to http://demos.telerik.com/aspnet-ajax/scheduler/examples/outlook2007/defaultcs.aspx, my CPU Usage stays around 15%. If I start moving the mouse around, back and forth, on top of the Scheduler, it gets up to 35-40%. Obviously a bunch of client events are being raised. So, my main question is whether we have any control over what gets raised, is there any way to minimize the memory footprint, etc?
Thanks!
0
Jeff Nafe
Top achievements
Rank 1
Rank 1
answered on 22 Mar 2010, 03:42 PM
I ran some profiling (dynaTrace) against the Scheduler and the attached image shows the results. This is what happens when I move the mouse around on top of the scheduler after it has completed rendering. As you can see, the CPU line shows the CPU resources spiking, and you can see how much javascript and rendering is going on even though our custom code isn't doing anything at these times.
We are really hoping that there is some way to throttle down (or turn off) some of these client events that are going on during this hovering and mouse movement. dynaTrace does show that during these mouse movements, literally thousands of client side calls are happening every second.
Thanks,
We are really hoping that there is some way to throttle down (or turn off) some of these client events that are going on during this hovering and mouse movement. dynaTrace does show that during these mouse movements, literally thousands of client side calls are happening every second.
Thanks,
0
Hello Jeff,
Yes, I've also ran dynaTrace on it, but unfortunately after disabling all the mouse hover events CPU continues to spike. Not that much, but still. I'm attaching a screenshot from dynaTrace with javascript disabled. Bear in mind that dynaTrace itself can cause some CPU overhead on slow machines.
After some tests we got to the root of the problem (or more precisely several roots) - in IE7 if :hover pseudo classes are not directly applied on anchor elements, severe slowdown occurs. It almost seems like the whole :hover handling there is completely separate from the rest of the CSS engine. If you have even one :hover pseudo class in your CSS that is not targeted at an anchor (even if the targeted element is hidden or not present on the page) every hover is slowed down most notably on nested elements and tables. The second reason was of course the events which apply the RadScheduler hovers as you noticed and smallest performance drain was from a mousemove event on the entire .rsContent area which is dedicated to the synced content scrolling.
So, first we removed the aforementioned mousemove event in all IE browsers, turned out it isn't needed there. Then we fixed the NumberOfHoveredRows property to disable the hover (and events) if set to 0. The CSS part though turned out rather problematic - we fixed the RadScheduler skins and base stylesheet and since it includes several other controls, we fixed their skins too. Looks like a stray input:hover can slow down IE7 even if it seems to target only input elements. Now with the next internal build (and the next service pack), if you disable the row hovers by setting NumberOfHoveredRows="0" in RadScheduler's definition and provided that you don't include any CSS that has .SomeClass:hover or AnyElementExceptA:hover, you would get CPU usage between 0 and 10% while hovering the RadScheduler rows. However if you put a RadGrid for instance on the same page, the slowdowns will return. We would continue to try and fix this issue in our skins, but currently not all controls have targeted anchor hovers.
I've updated your Telerik points for this report.
Greetings,
Kamen Bundev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
Yes, I've also ran dynaTrace on it, but unfortunately after disabling all the mouse hover events CPU continues to spike. Not that much, but still. I'm attaching a screenshot from dynaTrace with javascript disabled. Bear in mind that dynaTrace itself can cause some CPU overhead on slow machines.
After some tests we got to the root of the problem (or more precisely several roots) - in IE7 if :hover pseudo classes are not directly applied on anchor elements, severe slowdown occurs. It almost seems like the whole :hover handling there is completely separate from the rest of the CSS engine. If you have even one :hover pseudo class in your CSS that is not targeted at an anchor (even if the targeted element is hidden or not present on the page) every hover is slowed down most notably on nested elements and tables. The second reason was of course the events which apply the RadScheduler hovers as you noticed and smallest performance drain was from a mousemove event on the entire .rsContent area which is dedicated to the synced content scrolling.
So, first we removed the aforementioned mousemove event in all IE browsers, turned out it isn't needed there. Then we fixed the NumberOfHoveredRows property to disable the hover (and events) if set to 0. The CSS part though turned out rather problematic - we fixed the RadScheduler skins and base stylesheet and since it includes several other controls, we fixed their skins too. Looks like a stray input:hover can slow down IE7 even if it seems to target only input elements. Now with the next internal build (and the next service pack), if you disable the row hovers by setting NumberOfHoveredRows="0" in RadScheduler's definition and provided that you don't include any CSS that has .SomeClass:hover or AnyElementExceptA:hover, you would get CPU usage between 0 and 10% while hovering the RadScheduler rows. However if you put a RadGrid for instance on the same page, the slowdowns will return. We would continue to try and fix this issue in our skins, but currently not all controls have targeted anchor hovers.
I've updated your Telerik points for this report.
Greetings,
Kamen Bundev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
Hi Jeff,
Just to add - if you use custom RadScheduler skin, you will need to target all its :hover selectors to anchors too.
Greetings,
Kamen Bundev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
Just to add - if you use custom RadScheduler skin, you will need to target all its :hover selectors to anchors too.
Greetings,
Kamen Bundev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
Hi Jeff,
There is a new internal build available which should have all the fixes included. Let me know if they work for you.
Greetings,
Kamen Bundev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
There is a new internal build available which should have all the fixes included. Let me know if they work for you.
Greetings,
Kamen Bundev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.