ASP.NET Controls - Worth the Performance drop?

[kdub]

After doing some testing, I was extremely dissappointed in how quickly a
page's performace degrades after adding controls. Even a few Labels can cut
performance in half.

My question is: Is it worth it?

Anyone know if VS 2005 / Framework 2.x will have better performance of
controls?

 

[Matt Hawley]

Are you basing your performance after the first time the page is viewed?

Matt Hawley, MCAD .NET
http://www.eworldui.net

After doing some testing, I was extremely dissappointed in how quickly a
page's performace degrades after adding controls. Even a few Labels can cut
performance in half.

My question is: Is it worth it?

Anyone know if VS 2005 / Framework 2.x will have better performance of
controls?

 

[kdub]

No.

If you use a VS.NET Application Center Test Project to test a page, even
after the slow initial compile, you get horrible comparative performance at
even medium loads (20 - 100 users).

Kevin

 

[Ken Cox [Microsoft MVP]]

Make sure Viewstate is switched off on ASP.NET controls unless it is
actually required. The Viewstate bloats the page, making it take longer to
download and render.

 

[Matt Hawley]

Hmm, well my guess is that it probably wont due to how the framework is setup to handle things. Though, performance is generally increased with new versions, so I guess we'll have to wait until MS releases it. If performance is what you're looking for, I would suggest looking into Caching the page output.

Matt Hawley, MCAD .NET
http://www.eworldui.net

No.

If you use a VS.NET Application Center Test Project to test a page, even
after the slow initial compile, you get horrible comparative performance at
even medium loads (20 - 100 users).

Kevin

 

[Scott Mitchell [MVP]]

Make sure Viewstate is switched off on ASP.NET controls unless it is

actually required. The Viewstate bloats the page, making it take longer
to download and render.

Although if the Label control's state has not been changed
programmatically, then there will be no ViewState associated with the
control.

--

Scott Mitchell
(e-mail address removed)
http://www.4GuysFromRolla.com
http://www.ASPFAQs.com
http://www.ASPMessageboard.com

* When you think ASP, think 4GuysFromRolla.com!

 

[kdub]

I know about viewstate. It does help to turn it off, but performance is
still much worse when using controls. There is a 10% performance gain for
eliminating 5 labels in my example below.

Am I missing something, or are .NET Server Controls another 'easy to
develop, bad to use in the real world' tool?

I Don't mean to be pessimistic, i want to find a way to use them without the
performance hit.

-- Results --
frmA.aspx
No Controls, I have 5 functions that return a string in the CodeBehind, and
5
<%= funGetString1 %> tags in the ASPX page

Final Results
-------------
Total Run Time: 00:00:02:00
Total Iterations: 29,314
Total Requests: 56,307
Avg Requests/sec: 469
Avg Time to First Byte (msecs): 8.36
Avg Time to Last Byte (msecs): 8.40
HTTP Errors: 527
DNS Errors: 0
Socket Errors: 2,387


----------------------------------------
frmB.aspxControls
5 labels whose text property gets set in the OnLoad Event
ViewState is disabled on all labels

Final Results
-------------
Total Run Time: 00:00:02:00
Total Iterations: 26,530
Total Requests: 50,809
Avg Requests/sec: 423
Avg Time to First Byte (msecs): 9.86
Avg Time to Last Byte (msecs): 9.90
HTTP Errors: 76
DNS Errors: 0
Socket Errors: 2,298

 

[Fred Hirschfeld]

But are you using the label server controls for a reason? You should only
use server controls when needed for a specific purpose. If you are using
them because they are convenient, then your performance will suffer.

People will tend to use these even when a page does not need then such as an
add page (simply accepts data to add). Developers might be tempted to create
the server controls for the textboxes because they think it is appropriate,
but why not just use the HTML page to put an HTML textbox with name and then
onsubmit use the Page.Request.Params["FORM_ELEMENT_NAME"] to get its value.

Just because server controls are there (and make development easier) does
not mean they are the best to use in all situations.

Fred

 

[kdub]

And that Fred is my point.

Just because server controls are there (and make development easier) does
not mean they are the best to use in all situations.

Can you give me any situation where using a Label is best? Or even a
TextBox Server Control?
You can read TextBox values, on a postback, and write them to global
variables, then write some JavaScript to 'fill them back in' and it runs
better than using a TextBox with ViewState turned on.

I guess I started this thread because after 3 years of developing using
ASP.NET server controls, usercontrols, and the like, I was dissappointed to
find out just how much the performace suffered from doing so.

But are you using the label server controls for a reason? You should only
use server controls when needed for a specific purpose. If you are using
them because they are convenient, then your performance will suffer.

People will tend to use these even when a page does not need then such as an
add page (simply accepts data to add). Developers might be tempted to create
the server controls for the textboxes because they think it is appropriate,
but why not just use the HTML page to put an HTML textbox with name and then
onsubmit use the Page.Request.Params["FORM_ELEMENT_NAME"] to get its value.

Just because server controls are there (and make development easier) does
not mean they are the best to use in all situations.

Fred

I know about viewstate. It does help to turn it off, but performance is
still much worse when using controls. There is a 10% performance gain for
eliminating 5 labels in my example below.

Am I missing something, or are .NET Server Controls another 'easy to
develop, bad to use in the real world' tool?

I Don't mean to be pessimistic, i want to find a way to use them without the
performance hit.

-- Results --
frmA.aspx
No Controls, I have 5 functions that return a string in the CodeBehind, and
5
<%= funGetString1 %> tags in the ASPX page

Final Results
-------------
Total Run Time: 00:00:02:00
Total Iterations: 29,314
Total Requests: 56,307
Avg Requests/sec: 469
Avg Time to First Byte (msecs): 8.36
Avg Time to Last Byte (msecs): 8.40
HTTP Errors: 527
DNS Errors: 0
Socket Errors: 2,387


----------------------------------------
frmB.aspxControls
5 labels whose text property gets set in the OnLoad Event
ViewState is disabled on all labels

Final Results
-------------
Total Run Time: 00:00:02:00
Total Iterations: 26,530
Total Requests: 50,809
Avg Requests/sec: 423
Avg Time to First Byte (msecs): 9.86
Avg Time to Last Byte (msecs): 9.90
HTTP Errors: 76
DNS Errors: 0
Socket Errors: 2,298

 

[Fred Hirschfeld]

I understand and other the convenience there is not much. You get the server
event handling if you need and data binding. The Label would be useful so
that you don't have to reset the value as it is in the ViewState BUT as we
agree that is a performance drop. The textbox of course can be done with
some simple code to repopulate but again requires additional coding...

I tend to use the controls for the convenience and if I notice unacceptable
performance degredation then switch to some other method.

Some of the other things it they do (like dropdownlists) is to allow you to
rerender the page without hitting the database again for that page redraw.
This can also be accomplished with caching but when you are customizing
lists per user, this could get very server resource intensive.

Fred

And that Fred is my point.

Just because server controls are there (and make development easier) does
not mean they are the best to use in all situations.

Can you give me any situation where using a Label is best? Or even a
TextBox Server Control?
You can read TextBox values, on a postback, and write them to global
variables, then write some JavaScript to 'fill them back in' and it runs
better than using a TextBox with ViewState turned on.

I guess I started this thread because after 3 years of developing using
ASP.NET server controls, usercontrols, and the like, I was dissappointed to
find out just how much the performace suffered from doing so.

But are you using the label server controls for a reason? You should only
use server controls when needed for a specific purpose. If you are using
them because they are convenient, then your performance will suffer.

People will tend to use these even when a page does not need then such

as

an
add page (simply accepts data to add). Developers might be tempted to create
the server controls for the textboxes because they think it is appropriate,
but why not just use the HTML page to put an HTML textbox with name and then
onsubmit use the Page.Request.Params["FORM_ELEMENT_NAME"] to get its value.

Just because server controls are there (and make development easier) does
not mean they are the best to use in all situations.

Fred

I know about viewstate. It does help to turn it off, but performance is
still much worse when using controls. There is a 10% performance gain for
eliminating 5 labels in my example below.

Am I missing something, or are .NET Server Controls another 'easy to
develop, bad to use in the real world' tool?

I Don't mean to be pessimistic, i want to find a way to use them

without
the

performance hit.

-- Results --
frmA.aspx
No Controls, I have 5 functions that return a string in the

CodeBehind,
and

5
<%= funGetString1 %> tags in the ASPX page

Final Results
-------------
Total Run Time: 00:00:02:00
Total Iterations: 29,314
Total Requests: 56,307
Avg Requests/sec: 469
Avg Time to First Byte (msecs): 8.36
Avg Time to Last Byte (msecs): 8.40
HTTP Errors: 527
DNS Errors: 0
Socket Errors: 2,387


----------------------------------------
frmB.aspxControls
5 labels whose text property gets set in the OnLoad Event
ViewState is disabled on all labels

Final Results
-------------
Total Run Time: 00:00:02:00
Total Iterations: 26,530
Total Requests: 50,809
Avg Requests/sec: 423
Avg Time to First Byte (msecs): 9.86
Avg Time to Last Byte (msecs): 9.90
HTTP Errors: 76
DNS Errors: 0
Socket Errors: 2,298