Performance Tips?

[Brian Mains]

Hello,

The users of an application I built using the scheduler are asking if there is anything that can be done about performance issues experienced with the scheduler control.  Their situation is that they have a slower connection to access this application wirelessly, but there have been complaints on a LAN too...

I'm not sure what is the issue, because I am not experiencing this problem...  is there any general performance tips of how to tweak performance of the scheduler, or are you aware of any common performance pitfalls?

In my scenario, I'm using the scheduler, and not using the inline template.  So I use a customized form I built for the advanced edit/insert form.

Thanks.

[Paul]

Hello Brian,

Please refer to our Top Performance page for useful tips on the matter.

Greetings,
Paul
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[Brian Mains]

Hello,

This seems to have general performance statistics, which is great because someone else needed it.  I'm looking for more of a coding guidelines when writing custom code, to help make it performant.  Or settings to set to help increase performance...

Anything in that area.

Thanks.

[Peter]

Hi Brian,

There are some very useful general APS.NET Optimization Tips and Tricks which you can use to enhance RadScheduler's performance. Additionally, you can consider the Optimized Queries example.


Best wishes,
Peter
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[Mika]

Hi,

I have a similar problem with customers complaining about the performance of RadScheduler.

To be fair, in this case, there are other controls besides a RadScheduler on the same page (RadMenu, RadToolbar, RadTreeView). Anyway, the page is heavy on data, and feels sluggish. I did some benchmarking with YSlow and Chrome Speed Tracer, which might be helpful in your situation too.

I found with YSlow that my page was about 1MB in total size.

The problematic part is the generated HTML that has to be loaded each time. This is what you see with the "view source". In my case, the HTML took about 400KB. It contained:

ViewState ~ 150KB

Script (mostly JSON data) ~ 130KB

HTML ~ 120KB

Even with slower javascript engines it is likely that loading 400K will be a major performance issue, and it certainly pays off to minimize HTML. 

The first thing to do is to use compression. This reduced the page size in my case from 400K to 100K, a huge effect. But if this is not enough, you'll have to tune more.

Minimize inline javascript

Declare only necessary javacript variables in the ASPX. These are usually the ones where you need ClientIDs, like:

var scheduler = $find('<%= RadScheduler1.ClientID %>');

All other javascript should be loaded from external files and cached.

Try to disable ViewState

Easier said than done. For example, I had a hierachical navigation / drill down menu that displayed the number of events each year, month and day. I can't disable ViewState for this control, because it is tied to the RadScheduler's view (month, week, day, timeline). Surprisingly, I could disable ViewState in the RadScheduler itself without any immediate loss of functionality. This reduced (pre-compression) page size about 10%, but is a risky bet.

Try to limit data size

By showing less data on one screen you can in many cases improve both performance and user experience. But sometimes you need data for things like RadScheduler appointment tooltips, that are stored in appointment attributes and resources. These take easily a lot of space.

Even with aggressive tuning, the overall user experience is very much dependent on the browser's capabilities. With IE6 and other older browsers, any page with heavy RadControls barely works, and I wouldn't spend much effort to tweak them.

-mika-