asp.net : Too many controls?

[Peb0]

Hi all,
I've been building a multi-part "Request for Quote" form in asp.net.

I've built 6 user controls. 1 for common "Contact Info" and 5 (optional) others, specific to the product/services offered.

It's really not complicated. Just some .net controls with validation and submission. We have a multi-tiered framework, and I do use some data access, but as you can imagine, it's very minimal and terribly simplistic.

I noticed during development that my compile and prerender times have been growing, but not enough to throw any alarms.

Now that I'm ready to put it up for testing, I've found that our test web server is taking 7 minutes to render on the first pass! I've since timed my development machine and it's averaging 1 minute. Our live web server takes around 4 minutes. (We're used to 10-15 seconds.)

Across my 6 user controls, there are a total of 72 form fields. That along with validation would bring the total number of controls up to around 120-130.

Have I crossed some boundary that .net doesn't like? It may appear like a lot of controls, but I'm certain that if I did this in plain asp or did validation with my own custom javaScript, this page wouldn't be anything special and would pop up just as quick as any normal page.

Any comments or suggestions are welcome... Other than the obvious "Make 5 pages" suggestion.

Has anyone experienced a similar situation?

Thanks
PebĪ

[Ocean10000]

The first view of a new/edited page in dot.net 1.x is usually caused the page to be compiled into a dll and loaded into the application. That is why it is so slow the first load. After the first load it should run much faster after that.

if you want more info I found an article covering it more in detail.
ASPnetresources [aspnetresources.com]

[TheNige]

7 minutes is crazy...something has to be wrong. How big is the DLL in your bin folder?

[Ocean10000]

A 7 Minute first page view is a long time I agree. What type of hardward are you running for your production & development machines that are seeing this large of a first load time? Are you refreshing data from a database every time? If so how much data are you pulling down? Have you tried to validate the outputed html code to see if there is any rendering error that causeing the browsers to hicup also? I am just trying to get a clearer picture on what options are availible to tweak to reduce your load time, if any are possible with your current solution.

[Peb0]

Thanks for the replies.

I can't answer anything immediately but wanted to at least acknowledge my appreciation for the input.

Hopefully I can continue testing tomorrow and return with some more info.

PebĪ

[Peb0]

Ok, I'm back.
This thread is pretty cold but I thought I would at least close it off by explaining my final results.

My original numbers were not very clinical. I've since tried to conduct testing as controlled as I reasonably can.
My configuration and implementation has changed slightly since my original post, so these results are not apples to apples with my original concern.

Most notably, I have changed the web.config file to "<compilation defaultLanguage="vb" debug="false" />" as outlined by Ocean10000's reference article (thank-you).
I thought that compiling an asp.net application as "release" or "debug" was sufficient. (Though I cannot attest to how much of a difference this specific change has made.)

I have modified the global.asax file to inherit from a freely available dll.
Whenever the asp.net application is restarted the first time any page is accessed, this dll will navigate the website's folder structure and hit every .aspx and .ascx file to force them to compile.

TheNige - All 3 sites use a virtually identical set of dlls (they are all based on the same common framework). There are 16 dlls of which most are under 200k, 4 are 300-900k and 1 dll is 8.5Mb.

System(s) info
- Local - Dual core 2.8Ghz + 2Gb memory
- TestWeb - dual P3 933Mhz + 512Mb memory
- LiveWeb - dual P3 1000Mhz + 1Gb memory

Site #1 (200+ asp.net pages)
- Local - 30 seconds first page hit -> subsequent hits are instant
- TestWeb - 2:15 first page hit -> subsequent hits are instant
- LiveWeb - 4:15 first page hit -> subsequent hits are instant
NOTE: Before implementing the page walker, these were 5 seconds local, 24 seconds TestWeb and 29 seconds LiveWeb BUT for every page (no precompiling).

Site #2 (25+ asp.net pages)
- Local - 17 seconds first page hit -> subsequent hits are instant
- TestWeb - (this site is not on our TestWeb)
- LiveWeb - 2:28 first page hit -> subsequent hits are instant

Site #3 (2 asp.net pages)(with the page containing the 125+ .net controls)
- Local - 25 seconds
- TestWeb - 3:06 first page hit -> subsequent hits are instant (this is the one that was exceeding 7 minutes)
- LiveWeb - 3:55 first page hit -> subsequent hits are instant


The times for both TestWeb and LiveWeb can vary up to 30 seconds. We assume this is due to load.
The considerably better time on my development machine is easily explained just from hardware.
The fact that our TestWeb appears to be handling this situation better than our LiveWeb server is 99% due to the fact that our TestWeb is nearly dormant while our LiveWeb is... Live (customers are using it constantly).

As you can see, the times are near half my original 7 minutes, which is considerably better.

Upon implementing the "page walker" dll, the "first page hit" time went up everywhere, as expected, but oddly enough brought down the time for my "Super_large_.NET_form" page.
But of course the major benefit of the walker is that once the first page is rendered, every page in the site is ready as well.

Since development never ceases, it's difficult to say for 100% certain, what single thing was most important in bringing the time down.

Thanks everyone for the input.

We don't consider this resolved, but at least 3-4 minutes is more livable.

PebĪ

[macrost]

When you put it on the test server, did you make sure to compile in release mode, and in your web.config, change your debug to false? If you are running in debug, it will be noticeably slower than release mode.

Just a thought.

[Peb0]

Though I'm big enough to admit that sometimes I forget to change to "release" mode in the IDE before actually releasing my apps, usually I catch myself and rectify it.

If ever I experience any problems, this is one of the first things that I check (especially since most bug tracking is done in "debug" mode it makes itself obvious).

I have only just recently been made aware of the debug=false parameter in the web.config file, so now it's set properly at each installation.

PebĪ

[TheNige]

8.5 MB dll? Dang...must be a lot of code in there.

[Peb0]

>> 8.5 MB dll? Dang...must be a lot of code in there.

Ya,
It's the object of some... attention here in the office.

This is entirely OT, but this dll encapsulates our entire database(s) schemata(s), thereby giving us complete .net syntax to our data (from inline queries to parameterized stored procs, etc...).

On the one hand, it is extremely handy. On the other, it's quite wieldly. It's not a big deal for fat client apps, but our web development is starting to take a hit.

So to try and nudge this back on topic...
We know for certain that this dll was the cause of some of the webpage-first-load slowdown, but the initial concern of this thread was that, one page in particular was taking much much longer. The only thing really making it stand out was that it contained so many contols.

Can anyone attest that many .net controls on a web page would (or would not) have this effect?

PebĪ

[macrost]

Yes, I once wrote a CMS in .net, just playing around with having a "one page" windows feel app. That didn't work, obviously, as with all the controls, it did take forever on rendering, and such.

Another thought... if there are some things in your page that don't need viewstate, I believe you should be able to turn viewstate off for that control. Also, if you are using any datagrids, turn off "generate columns automatically" and that will save viewstate space, which in turn speeds up page rendering time.

[Peb0]

Good point.
I haven't played with the viewstate.
When I get a chance I'll see what difference it makes.

There aren't any datagrids.
The only data access employed by the page is when the form is "submitted" and then all I do is commit the entries to a datatable. So simple (which is one reason why I disapprove of our 8.5Mb data access dll).

Of the 72 form elements, most are multple choice type input, ie: drop down lists, etc... to simplify a customers options.

I can't imagine that viewstate is what's killing this page but I'd like to be surprised.

PebĪ

[Ocean10000]

You said in your previous message, that most of your options are multple choice right. Are these controls databound to the database in any way. If the choices are static,only thing changing is the selection, you can usually turn off viewstate for them without worrying to much (the catch is sometimes the events might not always fire the way you expect) if they have any on change events linked to them. Viewstate can grow massive very quickly if you are not carefull with it.

Another possible option for you is to collect the data in stages, example break that mongo page into 4 pages, save that data to a temp table, when they get to the last step just use a storeproc/sql to copy from the temp data table to finial destination table. Basicly having the user submit in smaller chunks usually is faster in most cases from my own experince.

Some Links they might help out also learning about ViewState and how it is used.
Understanding ASP.NET View State [msdn.microsoft.com]
Tip on Getting ViewState past Some Proxies [weblogs.asp.net]

[Peb0]

No, that's not really the problem. Once the page is compiled there are no speed issues. Every hit is near instantaneous, I don't have any problems with the functionality. There are no glaring issues with the design and nothing on the form is databound.

I'm not working on this project now, so I don't have any time that I can properly assign to it, but here's what I've been able to collect today.

Viewstate, when the page first opens = 1210 characters (no customer input)
Viewstate, with every single field chosen and filled with potentially legitimate data = 5180 characters
NOTE: This is extremely unlikely since this would mean a customer was looking for a quote on all 5 products. Realistically, we rarely quote more than 3, and typically only 1. (We have other pages that contain a lot more info in their viewstate, and have never had these precompile problems.)
Also, once the page has been compiled, changing data, validating, etc... is near instantaneous. It does not appear that viewstate is effecting performance that way.

I'm aware of breaking the page in to smaller portions, but would like to avoid it, for a couple of reasons.
1) I'm already done (I know, not a great reason)
2) .net pages don't pass data from page to page very nicely... I can do it, but effectively I would need to put 72 "hidden" form elements on each of the 5 pages, or like you mentioned, start writing to temp files or something.
The amount of effort to redesign this page this way would be more than outright changing this into a regular, single, asp page with javascript, and I'm sure then there would be no precompile lag.

PebĪ