connection pools yay or nay

  • Thread starter Thread starter Troy
  • Start date Start date
T

Troy

How does everyone feel about the use of Connection pools within a web
app? Is it highly recommended? Is it recommended with as much fervor
as was the do not store recordset or connection objects in session vars
in classic asp? Final question... if one were to use connection
pooling an a pretty high volume site, what should the number of pooled
connections be (I.e. - minimum in mem @ all times, max in mem... etc.)?

I ask cause I'm desperately trying to improve performance anywhere I can
in our application before the storm hits (before huge amounts of traffic
comes) and I've done just about everything there is to do.... converted
datasets to sqldatareaders where applicable, converted dynamic sql to
sprocs, minor performance tuning on the SQL box itself... I think this
is the last bastion of perf tuning for asp.net! thanks for any help or
opinions!
 
Depending on the volume, the number of connections in each pool should rise
and level off as the demand made by the ASP instances matches the capacity
of the server to handle the requests. We've seen heavily loaded systems make
do with 10-20 connections in the pool. The number of pools should remain
low-very low--one for each unique ASP process ID.

Frankly, when tuning performance, a lot more can be done by optimizing the
SP query plans, the table indexes and the way the procedure cache is
managed.

--
____________________________________
Bill Vaughn
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Seconded on Connection Pooling (its "on" by default, for a good reason).
Just ensure that all your data access is made with the same connection
string, otherwise you may have shot yourself in the foot with 100 or more
different potential connection pools.

--Peter
 
Back
Top