Here are some tips you can follow to optimize the RadScheduler control:
Data-binding: We recommend that customers bind RadScheduler only with appointments that are visible in the currently selected view. This makes performance a non-issue, as the views are limited to a few thousand appointments at maximum.
ViewState size: RadScheduler can work entirely without ViewState, if necessary. Customers pay the usual penalty of having to bind the data on each page load.
Number of requests: On-demand loading of scripts generates a few additional requests. Other than that, the number is rather low, as skins contain very little number of images. Using RadScriptManager and RadStyleSheetManager reduces the number even further.
Number of recurring appointments: Recurring appointments are stored as a single appointment with a recurrence rule. RadScheduler parses this rule and generates Appointment instances to render and show the end user. When the recurrence rule is endless or recurs on very short intervals, this may lead to many appointments being created in memory. RadScheduler allows you to add a limit—setting its
MaximumRecurrenceCandidatesproperty defines how many days can have an occurrence. The default is 3000. This feature does not apply to client-side binding.