Re: [HACKERS] Simmultanous Connections (fwd)

Don Baccus wrote:
> 
> At 11:46 AM 1/10/00 -0500, Karl DeBisschop wrote:
> 
> >Sounds like she may looking at postgres in PHP - at least PHP uses
> >that temporary and permanant connection concept.  My experience is
> >that PHP persistent connections are not worth it - the time to
> >establish a new connection is pretty small, and stale connections can
> >cause problems.
> Boy, persistent connections in AOLserver sure help a lot (ask Lamar
> Owen!).  If stale connections cause problems in your PHP environment,
> then the PHP persistent connection implementation needs some work.

Let's work some math.

Under AOLserver, using the pooled connection paradigm that it uses, for
5 databases, you would need to define 5 pools.  You then can control how
many instances of each pool can be opened at any given time.  So, if all
databases need the same number of connections average, you raise the max
on pool instances until users quit getting busy messages during normal
usage -- which usually , for a small number of users (~25 here), is only
2 or 3 instances.  

The persistent pooled model avoids fork() penalties -- after all, there
is overhead there, regardless of how small that overhead may be.

I have gone as far as reducing the instances to 1 here -- it's amazing
how few people actually do simultaneous accesses!  I currently am
running with an instance max of 3 -- and users get busy's very rarely.

With 90 users on a single database with 5 tables, an instance max of
10-20 would probably give less than a 10% busy rate.  And, as you add
more RAM, you can up your instance max to adjust.

I don't know how close to the AOLserver model PHP is (I think it is
pretty close, as the beta of PHP4 is buildable to run as a module under
AOLserver), but the concept of pooled persistent connections is a sound
one, and eliminates some grief (as long as you watch your transactions
-- don't want two connections that happen to share a pool instance to
share a transaction roolback!).  Plus, you can service that required
nnumber of users at varying satisfaction/busy levels depending upon your
current server resources.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11