There is this application I wrote several years ago that is in use for planning and reporting absences and vacation (also discussed here and most likely in some other article as well). Lately, I noticed the very same application working slower and slower to the point of users complaining. I decided to investigate.

 

First, some background. The application was written in .NET 2.0 using Web forms and Telerik RAD components. Yes I know. I really do. As I write this I am in process of porting it to .NET 4.5 so this is a perfect opportunity to also include some optimization fixes. Anyway… I fired up the application on production server in Mozilla with YSlow. I looked at the statistics and HTML size popped in my eyes. A whopping 6MB of HTML was being generated on home page.

Home page is used to display when people absences on departmental level. For easier presentation, data is displayed using Telerik’s RadScheduler. The first thing I did I went and checked web page generated source code. All normal. Except this tiny little hidden field named VIEWSTATE. Right. Cannot do much there, as application relies heavily on view state (but I have my TODO list set for next optimization). Still 6MB view state data is quite a lot. Even at this (mis-) use. I went to check out the database to see if number of requests stored could be an issue. The table used to display user absences had about 10K entries. Nothing out of the ordinary. Specially after 3 years.

Then I decided to look at the scheduler. I remember reading somewhere that RadScheduler like RadGrid use lazy loading (yeah, it was here). What if this was not true? Or what if I didn’t set that up correctly? Who knows? It was definitely worth pursuing. I altered my data source so that it only returns data for selected date period. I hit ctrl + refresh and Voila!, HTML size was now remarkably just 800K large. OK, it is still a lot, but that won’t improve until I obliterate view state. Still, it was nearly 8 times better than what it was out-of-the box!

In a fast-paced world demanding faster and faster development cycles, one still needs to stay on top of his game. It is even more important today, when various 3rd party APIs and controls and whatnot are available to us. I should have tested out this issue with release 1.0 instead of blindly believing what was written in documentation. I didn’t. Thankfully my mistake was an (relatively) easy one to fix.

Since I was doing optimization anyway, I also implemented most tricks shown in this amazing video from Mads Kristensen: Performance optimize your ASP.NET Web App.