Application Performance Question

[Darren]

This is a theoretical question, meaning I don't have any specific code
to show.

On a large ASP.NET 1.1 application what is the best way to populate a
forms data fields if you expect a large load? A large load meaning
over 200 users hitting the site 24/7. The goal is to not overload the
web server.

Options are

1. Databinding (doesn't scale well, heavy burdon on server).

2. Using code behind to populate/read the controls. For example:

TextBox1.Text = someDataValue;
....
somdDataValue = TextBox1.Text;

(What would be the performance issues with this)

3. Using <% =someDataValue %> in the aspx page. (Leads to old style ASP
type pages with mixing HTML and code)

4. Other options?

If this has been answered before then please point me in the right
direction.

Thanks!

 

[intrader]

This is a theoretical question, meaning I don't have any specific code
to show.

On a large ASP.NET 1.1 application what is the best way to populate a
forms data fields if you expect a large load? A large load meaning
over 200 users hitting the site 24/7. The goal is to not overload the
web server.

Options are

1. Databinding (doesn't scale well, heavy burdon on server).

2. Using code behind to populate/read the controls. For example:

TextBox1.Text = someDataValue;
...
somdDataValue = TextBox1.Text;

(What would be the performance issues with this)

3. Using <% =someDataValue %> in the aspx page. (Leads to old style ASP
type pages with mixing HTML and code)

4. Other options?

If this has been answered before then please point me in the right
direction.

Thanks!

These may be two other solutions:
1. Generate a template based solution that is rendered directly via a
stored procedure. This may prove to overload the db engine.
2. Generate XML from database, render this XML to client along with XSL to
convert it to XHTML.

 

[Guest]

First, what kind of web server are you talking about? 200 users sounds pretty
small to me. Users can only click so fast, so there is plenty of lag to scale
up.

Let's see your potential solutions:

1. Databinding (doesn't scale well, heavy burdon on server).

What do you mean by data binding?

If you follow the normal ASP.NET databinding, it will certainly scale as

2. Using code behind to populate/read the controls. For example:

Sure, I do this all the time, especially when you end up having to use heavy
templating or overriding normal event paths to get data on a form. It is less
maintainable, as none of your code is declarative, but it works.

I do not see this as extremely scalable compared to ASP.NET databinding,
however.

3. Using <% =someDataValue %> in the aspx page. (Leads to old style ASP
type pages with mixing HTML and code)

For the record, this is databinding. Possibly kludgy data binding, but data
binding none-the-less.

4. Other options?

I still do not see 200 users pounding a machine to the point of submission
unless you are throwing too much data at them in one call. If so, redesign is
a better option. In general, if you are putting out more data than fits on a
single screen, except in search (and possibly reporting) scenarios, you are
going overboard. Another possible gotcha is "SELECT *" on tables where you
only bind a small amount of data. Both are instances of bad design (or
potentially bad design).

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Guest]

Darren,
Besides what Cowboy had to say, which pretty much covers the bases, you need
to think about caching. If you have a form that is going to get populated
with the same Database information for every user, it makes no sense to make
a database call for every user. Cache the data, and take it out of cache for
your data binding operation. Same with Session - if you have data that a user
will / may use more than once during their visit to your site.
Peter

 

[john smith]

These may be two other solutions:
1. Generate a template based solution that is rendered directly via a
stored procedure. This may prove to overload the db engine.
2. Generate XML from database, render this XML to client along with XSL to
convert it to XHTML.

I would definitely pick that #1 dead least, well after even databinding.
So many things are wrong with this I don't even know where to start.

You get code for formatting data in the SQL query, as well as other code
that ought to be in the presentation layer i.e. all the extra markup it
generates (and arguably presentation code should live in the
presentation layer - not in a data persistence layer), which makes your
application harder to maintain (mixing layers does that - whether it
s business logic or presentation code in sprocs, bypassing layers, etc),
needs some extra queries for those pages that other apps won't use (more
burden, less efficient, and I can tell you the DBA won't be happy),
harder to maintain (simple presentation layer/page changes will often
need the sprocs to be updated), puts tons more unecessary load on the DB
server (making everything slow in the process), which alone is a reason
not to do it as DB servers are usually licensed per CPU (tens of
thousands of $$ per CPU) whereas an extra server (or extra resources)
for processing your ASP.Net pages will most likely be far cheaper. I
could go on about this for 3 straight weeks! If anything it reminds me
of this http://thedailywtf.com/forums/40438/ShowPost.aspx

#2 is somewhat better, but it's still (IMHO) quite lacking/inferior to
his initial options.