Slow performance

[Daniel]

Hello,

My company is considering using your Scheduler component in our application, but we have some reservations due some performance issues we've run into with large datasets. When loading lots of appointments (175 users over a 1-month period, about 250 appts.), the performance is not very good (10-second response time, ~1MB response to postback), and this is over an intranet. We're going to be deploying whichever scheduler we choose in an internet application, where it is critical that the performance be top-notch, so if we can't get it to perform quickly over our intranet, we won't be able to use it, unfortunately, as much as we like the looks and features of the Telerik scheduler. I've tried out a few other schedulers, and the response time for the same dataset is much faster, so I know it's not the size of the data itself causing the slowdown. As best I can I tell, the slowdown seems to be due to the rendering stage. Is there something we can do to reduce the size of the response returned to the postback and to speed up the rendering of the appointments? Also, it's making 20+ requests to WebResource.axd for scripts -- is there a way to tell it to combine, minify, and gzip these scripts into a single request so that it doesn't hamper performance?

Thanks,

Daniel

[Roatin Marth]

Script combining is supported by RadScriptManager OOTB. Just put your scripts inside the <CompositeScript> element.

Re performance, one issue we found with the control is it does not filter out appointments on the server that will not be rendered in the current view. For example if in the current month view there are 250 appointments, only a small subset of them are actually visible on the control (by default max 2 per day), the serverside code still pulls them all down to the browser. Telerik has it on their radar to fix it for the SP1 release of the 2010 Q1 release, see http://www.telerik.com/support/pits.aspx#/public/aspnet-ajax/858. Until then we've filtered out recurring appointments on the server, and patched the client-side code ourselves to re-create them from the RecurrenceRule string on the client, in order to avoid the huge JSON payload you get from the server.

Their appointment rendering is also being improved for speed (esp in IE). See http://blogs.telerik.com/blogs/posts/10-03-12/improved_appointment_rendering_in_radscheduler_for_asp_net_ajax_q1_2010.aspx which delves into the nuts and bolts.

[T. Tsonev]

Hello,

Thank you for your interest in our products.

We offer ready solutions to common performance problems - script and stylesheet combining and compression, viewstate and ajax compression, CDN support.

They're all very easy to use. Start by replacing ScriptManager with RadScriptManager and placing a RadStyleSheetManager on the page:

<telerik:RadScriptManager runat="server" ID="RadScriptManager1" />
<telerik:RadStyleSheetManager runat="server" ID="RadStyleSheetManager1" />

They require a common handler that you can register through the action tag in design time. I'll make a small correction to what Roatin said, the script combining is enabled by default for all RadControls.

My recommendation is that you evaluate RadScheduler in isolation, as using a complex page layout makes it harder to track down performance issues. In particular, RadSplitter with a fluid layout tends to slow down the rendering quite a bit as it requires multiple redraws. By understanding these implications you'll be able to make an informed decision on how to build your page.

I hope this helps.

Kind regards,
Tsvetomir Tsonev
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.