views:

365

answers:

5

Hi,

I'm investigating an asp.net web application that extensively uses User Controls on each page. Most pages contain around 10-20 user controls. The User controls seem to be the visual representation of the business objects (if that makes sense), although at a finer granularity such as each tab of a tab control having its contents in a user control. The project itself has over 200 user controls (ascx files).

The performance of the application is very poor (and the reason I'm investigating). Each event (such as a click or dropdown selection etc) requires about 5 seconds for the page to load (10 seconds whilst in visual studio). The application has no use of Ajax.

Tracing is painful as the aspx pages themselves have no code in the code-behind as the user controls look after all of this, so tracing a single page requires trace statements in all the user controls that are on that page.

I actually think that having each user control look after its business code and being re-usable is a smart idea, but is an excessive use of user controls going to incur a performance hit? Does this seem like the structure of an asp.net application that was written by someone with a strong WinForms background?

EDIT
thought I should add that i'm not questioning the use of user controls (or even the amount) but simply whether having so many on a page that all accomplish things (each user control connects to the database for example) will generally cause performance problems...For example, if just one user control postsback to do something, what about the processing of all the others, some are visible and some aren't...@David McEwing mentioned that he had 40 optimised user controls performing etc, but if the developer was WinForms based or "not familiar with asp.net", then how are they going to make sure each one is optimised...

EDIT2
After getting a sql statement trace, the same calls for data are being executed 5-6 times per page call for each event as the different user controls require data that is not stored commonly e.g. each user control in the tab (mentioned above) makes the same call to populate an object from the database...I'm really not here to accuse user controls of being the problem (should i delete the question?) as clearly the problem is NOT user controls but with the use of them in this particular case...which I believe is excessive!

+2  A: 

I take it that you are not familiar with applications which use so many user controls?

It sounds like you may be jumping to the conclusion that this unfamiliar aspect of the application is the cause of the unfamiliar bad performance. Instead of making assumptions, why not try one of the following profiling tools, and find out:

These can all do memory and CPU profiling of ASP.NET applications.

John Saunders
I'm not too familiar with this amount of user controls...I certainly use them in all the asp.net projects I've worked on, but I tend to see each page as being mapped closer to a business object and then using user controls on those pages instead of all parts of a page being made up of user controls...
davidsleeps
+1  A: 

I believe that one of the key purposes of UserControls is code reuse. That is, if the same functionality occurs on multiple web pages, then it is better to create a UserControl for it. That not only saves the developer from writing (or copying and pasting) the same code to several web pages, but it also makes maintenance much easier. Any change made to the UserControl is implemented automatically everywhere the UserControl is used. The maintenance developer doesn't have to worry about finding all the different places that the code needs changing.

I'm not sure if a single-use UserControl is as effective. They do encapsulate and segreate the code, which is nice on a busy web page.

Can you ascertain whether your UserControls are reused, or are many of them only used once.

DOK
Encapsulation is actually the key purpose of a user control, and reuse is one of the benefits of good encapsulation.
Rex M
It's mixed. All visual elements of the web application live in user controls, so some appear on all pages (such as a menu, header etc which makes sense) but others appear only on a single page that is relevant to the control...
davidsleeps
+4  A: 

10-20 (or even hundreds) User Controls alone is beyond trivial. The presence of the controls themselves, and the idea of encapsulation, is definitely not the source of your problems.

It's impossible to say precisely what the problem is without actually profiling the application of course, but based on my experience I can say this:

What is more likely is the specific implementation of the business logic inside each user control is poor. With postbacks taking as long as you describe, each control probably looks back to your DAL for its own data on each request. This can be mitigated by two things:

  • Make sure user controls cache all their data on first load and never re-load it unless explicitly instructed to (usually by an event from a lower-level service)
  • Ensure the controls all use a set of common services which can reuse data. E.g. if two controls need access to the customers list, and they are executing in the context of the same request session, that should only require one customer list lookup.
Rex M
I agree perfectly with your ideas (and there ideas I hold as well)...and this re-inforces my feeling that the application wasn't developed by someone familiar with asp.net as the session isn't used except to hold a user id variable and each user control does access the same DAL methods each time
davidsleeps
+1  A: 

I agree with Saunders about doing some profiling to determine the impact certain things have.

Note that you can get some free stress-testing tools for IIS here: http://support.microsoft.com/kb/840671

I will say, though, that having too many controls is probably not a good thing, IMHO. Without knowing more, I'd tentatively say 20 is too many.

Noon Silk
"20 is too many"? Do you have any sources you can cite on this?
Rex M
My source is my opinion, as stated. 20 custom user controls is a lot. It basically implies the page is doing 20 things or showing more than 20 bits of data, which is a lot for a single page (in my experience).
Noon Silk
I agree. Especially if a tab control is not being shown but it is still creating it's user controls then this would cause some unnecessary overhead, but without knowing more I have sucessfully used 40+ optimised user controls on a page, for very specific purposes and business rule encapsulation.
David McEwing
@Silky it seems like that is making a big assumption as to what scope of work each individual control represents. I am just worried for the poor beginner who stumbles across this and see "20 User Controls on a single page is too many" without enough context, like maybe "20 UCs which each do a herculean amount of work is too much for a single page".
Rex M
It's not a big assumption at all; and there is a lot of context to my post. I don't think there is anything to worry about. Personally I worry about the newbie coming along and seeing that he/she should be creating 20 user controls just for a single page. And what does a user control represent but a grouping of work/items to be done?
Noon Silk
@silky a user control could just as likely encapsulate a trivial workload as a heavy one.
Rex M
Rex: Exactly; so regardless it is holding 20 'items'. And it's implied that it's more than a single ASP.NET control otherwise you'd just be using that, so my point remains that it is indicative of a lot of work being done on that page. And unless it's handled gracefully (may well be) it's at least a *sign* that investigation into the reasons why is required.
Noon Silk
+2  A: 

I'll put myself firmly in the camp of folks that suggest there is no hard limit to a number of user controls that should be used on a page. It sounds like application-wide tracing is in order here instead of page-level tracing. It may very well be that a handful of these controls is causing the problem. Heck, it could be a single control causing all the fuss. However, since it's impossible to make any assumption about the level of resource-usage that the "average" (if there is such a thing) user-control takes up, it's likewise impossible to suggest a limit. Otherwise, we'd be able to come up with similar limits to the number of members to a class or the number of stored procedures to a database.

Now, if we're talking about 20 complex user-controls that are each retrieving their own data with each refresh and each with a bunch of sub-controls using ViewState whether needed or not, then yeah, that's a problem. Still, it has more to do with overall design than with there being too many controls. If, on the other hand, they've created a common user control to act as nothing more than the composite of a label to the left of a textbox (or maybe even every combination of label + user-actionable control) and have sprinkled this control throughout the app, I can imagine that you'd get a bunch of these on a page and I can't see why that would necessarily hurt anything.

Lloyd McFarlin