ASP.net and SQL impersonation for High Scalability

[Gordowey]

Hi all, I would like to ear your opinion about the best approach for
and ASP.net with high workload traffic (High number of visitors) using
SQL DB

Consider the following scenario:
- Website with 10.000 visitors/day. (and can grows faster. High
Scalability is one of teh requirements)
- Single W2k3 server (no farm),
- ASP.net 1.1 (or ASP.net 2.0) web site
- SQL 2000 (or 2005)

I have the following questions:

1. - I am using "forms" authentication (internet users don't have
a windows account), right?

2. - What about the SQL user? Is it enough to create a single sql user,
and all my visitors connect with this user (i.e.: sqluser)? Only one
sql is enough? and for High Scalability ?

3.- I am using System.Data.SqlClient lib: Should I be worried about
simultaneous connections or Does the SqlClient lib resolves it?

5. - What about connection pooling? Is necessary to implement it?


6. - Is there a better solution for this?

thanks you very much

Any help, comment would be appreciated


Alberto

 

[Cowboy \(Gregory A. Beamer\)]

INLINE

Hi all, I would like to ear your opinion about the best approach for
and ASP.net with high workload traffic (High number of visitors) using
SQL DB

Consider the following scenario:
- Website with 10.000 visitors/day. (and can grows faster. High
Scalability is one of teh requirements)
- Single W2k3 server (no farm),
- ASP.net 1.1 (or ASP.net 2.0) web site
- SQL 2000 (or 2005)

I have the following questions:

1. - I am using "forms" authentication (internet users don't have
a windows account), right?

Correct, although there are ways to have accounts. Commerce Server comes to
mind.

2. - What about the SQL user? Is it enough to create a single sql user,
and all my visitors connect with this user (i.e.: sqluser)? Only one
sql is enough? and for High Scalability ?

This definitely makes things scalable, as you have a single pool to work
from with one user. But the question of accounts is more a security issue,
as all auditing is on your shoulders if you use forms auth. This is not a
bad thing, just a reality.

3.- I am using System.Data.SqlClient lib: Should I be worried about
simultaneous connections or Does the SqlClient lib resolves it?

The pooling mechanism in the SqlClient lib handles pooling.

5. - What about connection pooling? Is necessary to implement it?

Whether you take control or let ADO.NET handle it, there is a pool, at least
by default.

6. - Is there a better solution for this?

If your focus is the number of users, I see nothing wrong with your
approach. I think you might want to cluster the web server and the database
server at some point in time (at minimum, add a failover), but the
programming approach is not a major concern.

 

[Gordowey]

INLINE




Correct, although there are ways to have accounts. Commerce Server comes to
mind.


This definitely makes things scalable, as you have a single pool to work
from with one user. But the question of accounts is more a security issue,
as all auditing is on your shoulders if you use forms auth. This is not a
bad thing, just a reality.


The pooling mechanism in the SqlClient lib handles pooling.


Whether you take control or let ADO.NET handle it, there is a pool, at least
by default.


If your focus is the number of users, I see nothing wrong with your
approach. I think you might want to cluster the web server and the database
server at some point in time (at minimum, add a failover), but the
programming approach is not a major concern.

Thanks Gregory,..for your clear explantion..that helps me a lot.

Alberto