Performance

[Peter Zolja]

I'm in a quest to optimize my pages, here's what I found. Let's start with a base rendering time of 9ms, a few standard controls, about 3 database calls. All this adds up to 9ms; for what it does not too bad. I measure this by turning tracing on and hitting refresh about 10 times and calculating the average rendering time (I skip the first two to avoid the warm-up times).

OK, now I'm going to add a RadMenu, just a simple instance, absolutely no items in the menu, skinning disabled... the bare minimum. Doing this jumps the render time from 9ms to 14ms, so 5ms just to add the menu on the page. I continue by adding some code that dynamically builds some menu items, about 10 menu items (including subitems). My average is now 15ms, so that code must have added 1ms. Fine, now I leave the code that builds the menu and override OnPreRender where I remove all the items in the menu. After doing this my average drops back to 14ms; my conclusion: that extra 1ms was spent rendering the output, not in what I'm doing, but let's not be too picky, let me move on to RadPanel.

I take out the OnPreRender code so my average goes back to 15ms, and I add an empty RadPanel. Same story as with the menu, just a simple panel with no items, no skin, nothing. My average is now 22ms, a 7ms jump just for adding a RadPanel that does absolutely "nothing". Next step is to add the code that builds some items, about 3 RadPanelItems each with a menu inside. Each menu has between 1 and 4 items, so nothing big. Doing this my average jumps to 34ms. So I'm thinking: 'I must be doing a lot of work for 12ms.' I do the same trick I did for the menu and on pre-render I remove the items but leave the code that generated them. After I do this the rendering time goes back down to 22ms, so whatever I'm doing to build the items doesn't really add up to much.

So, let me summarize all this. I started with 9ms which includes 3 database calls (fairly complex queries) and a number of other controls. Adding a menu with about 10 menu items adds 5ms and adding a panel bar adds another 19ms for a total of 24ms, time that does not include the code I use to generate the items. My page went from 9ms to 34ms, 3 fold increase. To say the least I'm not impressed.

[Ed]

So are you saying that the RadPanelBar is inherently slower than RadMenu?  Or that they both slow the page down without actually doing anything?

Incidentally, when you say you turned tracing on, which tool were you using?  Just curious -- I used Firebug for my timings (in my previous post), so I can recommend that if you are not happy with your own tool.

[Peter Zolja]

They're both slower than what I would like them to be. RadPanelBar seems to be slower than RadMenu. I just can't imagine what they're doing that would slow down the render time so much. I have a functional page (without menu or panelbar) that goes through the entire lifecycle of the page, and there's a lot of stuff going on behind the scenes, in about 9ms. Adding a menu and a panelbar to the page triples the serve-side processing time.

Now, 34ms may not sound like a lot, but you can actually feel the difference on the local machine between 9ms and 34ms. When you have this on a high traffic site it could mean the difference between 110 (for 9ms) and 30 (for 34ms) requests per second.

You can turn tracing on for each page (http://www.asp101.com/articles/robert/tracing/default.asp) which basically reports back how many ms it spent rendering the page and where, as well as a grand total. This is not as precise as using a profiler, but it's accurate enough. For this reason, as I explained, I ignored the first two hits to allow the page to "warm up." Then I repeated the test (basically hit refresh in the browser) for ten times and calculated the average. 

I hope this helps.

[T. Tsonev]

Hello Peter,

While I was not able to exactly replicate your results, I agree that server-side performance is very important. We, generally focus on client-size performance, as unoptimized code there can lead to very serious performance penalties in the order of seconds. Lately we are also focusing on the server-side performance and we try to optimize the most time-consuming operations. For example, we pay special attention to avoid using reflection.

The upcoming Q3 release will incorporate a number of such optimizations. But there are a couple of more things that you might try. Using output caching, for example, has a huge potential. We have a help topic that describes how to use RadMenu in an user control with enabled caching.

We have a special site section dedicated to performance too. Be sure to take a look at it too.

Greetings,
Tsvetomir Tsonev
the Telerik team

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

[Peter Zolja]

I'll try to make a test case for you when I get a little free time. I cannot use output caching, unfortunately, because each page is a little bit different -- especially in the case of PanelBar -- so I would end up caching most of the pages which would eat up the memory on the server.