[thelist] best practice question

[Ken Schaefer]

I'd guess you'd gain something from caching the connection string, since
you'd probably avoid ever having to read the actual web.config file from
disk.

However, the real gain is in using the underlying Windows data infrastructure
to provide connection caching. This allows you to abstract the number of
users of your web application from the users that the DBMS sees. As far as
the DBMS is concerned, there are 200-300 connections. Your web application
might have thousands, or hundreds of thousands, of users. The Microsoft data
access infrastructure handles managing the stubbed connections, and matching
them up to physical connections when required.

For the project I'm working on at the moment, we have 23 load balanced web
servers in the web tier that are supposed to handle just over 50,000
concurrent users, and 2500 concurrent reqs/second. For the main SQL Server
backend, we have a set of clustered Unisys ES7000s. For those that aren't
familiar with ES7000s, they run Windows Server 2003 Data Center edition, and
can have up to 64 CPUs each. Even still, I think SQL Server would struggle
with 50,000 concurrent connections. Instead, we'd see a small fraction of
that number, as the data infrastructure components abstract the physical
connections from our SqlConnection objects in ADO.NET.

Cheers
Ken

-----Original Message-----
From: thelist-bounces at lists.evolt.org
[mailto:thelist-bounces at lists.evolt.org] On Behalf Of Ben Joyce
Sent: Wednesday, 9 August 2006 10:07 PM
To: thelist at lists.evolt.org
Subject: Re: [thelist] best practice question

Useful thread, interesting feeback here.

I'm spwaning and killing my connections on each request and reading
the connection string from web config.  I'd prefer to manage the
connection this way, but do you recommend caching the connection
string?

Cheers,

Ben

On 8/9/06, Ken Schaefer <Ken at adopenstatic.com> wrote:
> In addition to Peter's excellent analogy, the technical details behind why
> the analogy is good:
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmdac/html/
> pooling2.asp
>
> Cheers
> Ken
>
> --
> My IIS Blog: www.adOpenStatic.com/cs/blogs/ken
> Tech.Ed Sydney: learn all about IIS 7.0 - See you there!
>
>
> : -----Original Message-----
> : From: thelist-bounces at lists.evolt.org [mailto:thelist-
> : bounces at lists.evolt.org] On Behalf Of Peter Brunone (EasyListBox.com)
> : Sent: Wednesday, 9 August 2006 6:01 AM
> : To: thelist at lists.evolt.org; thelist at lists.evolt.org
> : Subject: Re: [thelist] best practice question
> :
> : > Okay, but then you still need to instantiate the object "dbConnect" on
> : > as needed basis. What I'm wondering if there is a way to only
> : > instantiate it once per application, and then refer to it as many times
> : > as needed.
> :
> :    There is, but -- as Chris pointed out when responding to what he
thought
> : was my suggestion of something similar -- it REALLY doesn't scale well
for
> : multi-user applications.  I think the following analogy from
> : http://www.learnasp.com/freebook/asp/sessionoverview.aspx really applies
> : here:
> :
> : A Porsche seems really fast to get anywhere... until you have 3-10
> : passengers. Then a mini-van will beat it because you have less trips to
> : make. In client-server terms the Porsche doesn't SCALE WELL for more than
2
> : passengers. On the other hand, when a group of 100 wants to go to
Atlantic
> : city for the weekend we recommend a Tour Bus. However, someone taking a
> : Tour Bus to the grocery store has anecdotal evidence it is not as fast as
a
> : Porsche.
> :
> :    Storing one connection object for repeated use is a great idea...
until
> : more users need to get to it at once.
> :
> :    If you want to abstract out the connection creation, you'd do better
to
> : use the approach I mentioned earlier (not that it's the best or only way)
> : and just add methods as needed, depending on what you need from the
object.
> :
> : HTH,
> :
> : Peter
>
> --
>
> * * Please support the community that supports you.  * *
> http://evolt.org/help_support_evolt/
>
> For unsubscribe and other options, including the Tip Harvester
> and archives of thelist go to: http://lists.evolt.org
> Workers of the Web, evolt !
>
-- 

* * Please support the community that supports you.  * *
http://evolt.org/help_support_evolt/

For unsubscribe and other options, including the Tip Harvester 
and archives of thelist go to: http://lists.evolt.org 
Workers of the Web, evolt !