Kevin Kembel
Top achievements
Rank 1
Rank 1
Kevin Kembel
asked on 22 May 2011, 10:12 PM
We're having troubles with performance on our implementation of the RadScheduler. We have a rather fully-featured RadScheduler on the page, and a RadAjaxManager that handles postbacks. Our clients have reported anywhere from 4second to 20second round-trip load times when browsing through the scheduler.
We've sped up processing time on the server to about 1.5s (there are 5 sets of resources that are loaded, which vary depending on the user). We've implemented static content compression, dynamic content compression (IIS 7), and RadCompression which has sped up response delivery time to about an average 1s. What we've noticed is that the big variance in performance is because of the request size. When we make a request, like paging the radscheduler back 1 week, it loads in async, and the request header shows:
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 248485
The request's content length is usually between 230KB and 270KB, even when there are zero appointments loaded on the scheduler for the week being viewed. On a faster client connection, it is only taking about 2s to send the request to the server. But on some client connections, that same request is taking about 10-15 seconds just to POST, before taking 2.5s to process and provide a response.
Is this normal? Is there anything that we can do? Is this the resource data being included in every request? In our 5 resource types, we have a total of about 1200 resources, they include things like a user list, a location list, etc.
Because of a bug in the OnClientAppointmentMoveEnd(), we're not able to implement a client-side web services solution yet.
We've sped up processing time on the server to about 1.5s (there are 5 sets of resources that are loaded, which vary depending on the user). We've implemented static content compression, dynamic content compression (IIS 7), and RadCompression which has sped up response delivery time to about an average 1s. What we've noticed is that the big variance in performance is because of the request size. When we make a request, like paging the radscheduler back 1 week, it loads in async, and the request header shows:
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 248485
The request's content length is usually between 230KB and 270KB, even when there are zero appointments loaded on the scheduler for the week being viewed. On a faster client connection, it is only taking about 2s to send the request to the server. But on some client connections, that same request is taking about 10-15 seconds just to POST, before taking 2.5s to process and provide a response.
Is this normal? Is there anything that we can do? Is this the resource data being included in every request? In our 5 resource types, we have a total of about 1200 resources, they include things like a user list, a location list, etc.
Because of a bug in the OnClientAppointmentMoveEnd(), we're not able to implement a client-side web services solution yet.
3 Answers, 1 is accepted
0
Accepted
Hi Kevin,
Indeed, Web Service binding is likely to give better results in terms of performance. If the OnClientAppointmentMoveEnd bug is all that is preventing you from utilizing Web Service binding, I am glad to let you know that we have just made a fix and you can test it with the internal build that will be uploaded later this week.
Regards,
Peter
the Telerik team
Indeed, Web Service binding is likely to give better results in terms of performance. If the OnClientAppointmentMoveEnd bug is all that is preventing you from utilizing Web Service binding, I am glad to let you know that we have just made a fix and you can test it with the internal build that will be uploaded later this week.
Regards,
Peter
the Telerik team
Browse the vast support resources we have to jump start your development with RadControls for ASP.NET AJAX. See how to integrate our AJAX controls seamlessly in SharePoint 2007/2010 visiting our common SharePoint portal.
0
Kevin Kembel
Top achievements
Rank 1
Rank 1
answered on 24 May 2011, 04:58 PM
Hi Peter,
Thank you very much for including the fix in the internal build for this week. We will schedule some time in the next few months to move our implementation to web services, should resolve our performance problem. Kind of an obvious suggestion to others as well, but we reduced the size of the POST request by trimming out extra attributes in our resources that we weren't using, and disabling viewstate for all controls on the page that don't require it. Never made a huge difference, web services will still be required for us, but it did help if anyone else is struggling with a similar problem.
Thank you very much for including the fix in the internal build for this week. We will schedule some time in the next few months to move our implementation to web services, should resolve our performance problem. Kind of an obvious suggestion to others as well, but we reduced the size of the POST request by trimming out extra attributes in our resources that we weren't using, and disabling viewstate for all controls on the page that don't require it. Never made a huge difference, web services will still be required for us, but it did help if anyone else is struggling with a similar problem.
0
Hello Kevin,
It is nice to learn that now you can proceed with the planned implementation of Web Service binding.
Also, thank you for sharing your findings and techniques on performance improvement in the forum.
Greetings,
Peter
the Telerik team
It is nice to learn that now you can proceed with the planned implementation of Web Service binding.
Also, thank you for sharing your findings and techniques on performance improvement in the forum.
Greetings,
Peter
the Telerik team
Browse the vast support resources we have to jump start your development with RadControls for ASP.NET AJAX. See how to integrate our AJAX controls seamlessly in SharePoint 2007/2010 visiting our common SharePoint portal.