Re: [HACKERS] Simmultanous Connections (fwd)

At 01:38 PM 1/10/00 -0500, Karl DeBisschop wrote:

>This isn't really a hackers issue, so I'll try to be brief but also
>give a little more info than I originally did.  Maybe any further
>discussion would be best placed in pgsql-general.

Perhaps.  I'll give one brief answer here, though.  It probably
doesn't hurt the developers to see how their product is used in
real-life scenarios anyway...

>Basically, I think it may depend on the use - for our website, we get
>connections from a variety of sources - most of them don't repeat for
>a long time, if ever.  Which means a bunch sit around at any given
>time, never to be reused.  If the new connections come fast enough,
>this can translate to real problems unless they timeout quickly, which
>defeats the purpose.

>That being said, maybe the PHP implementaion does need some work, or
>maybe there are site parameters we could tune to make it work.  But
>whenever we use it, we do eventually end up in trouble as a result.

My short answer: yes, it does need work if it works as you describe.
The whole point of pooling persistent connections is to allow re-use.
It sounds like either PHP makes it hard/impossible or that (maybe?)
you folks haven't quite figured out how fully exploit their implementation
of pooled connections.

>So, personally, I don't recommend it in situations where alot of
>different clients will be connecting to the DBMS - at least if low
>maintennence is a key goal.

The problem isn't persistent connections, the problem is the particular
implementation you're using.  AOLserver's implementation is trouble
free, for Postgres, Sybase, Oracle, and Solid.  And totally
transparent to scripts and dynamic pages (other than SQL differences
due to the dbs themselves).  The PHP folks are making it available 
within AOLserver, as Lamar Owen has pointed out.  If they also plug
into the AOLserver implementation of pooled persistent database
connections, then PHP users will also have a platform available which 
reliably supports such connections.

>> Forking a new backend is actually considerably more expensive then
>> just passing back the PID of an existing backend...
>
>>From the point of view of the server, absolutely.  But that connection
>time is still a very small part of the user's total trransaction time.

Depends on how you're using the database.  If you're using it to
personalize pages, for instance, you'll be using a lot of simple,
quick selects.  If you're only using the database for complicated,
slow queries then perhaps you're right.

Let's put it this way ... folks who have a lot more experience than
me at running very busy database-backed web sites have observed that it
DOES make a large difference in the scalability of a site.  These,
though, are sites make heavy use of the database when serving up
pages.

If forking weren't a problem, the Apache folks wouldn't've bothered
building modPerl, for instance...

>And, although I am making alot of guesses as to the nature of the
>planned DB will be, my guess is that overall machine load will not be
>so high that the process forking becomes critical.  My guess is that
>support will be hard to come by in alot of public school environments,
>so I'd guess their building for trouble-free operation before speed.

Nothing to disagree with here, other than the fact that my own 
personal experience tells me that persistent connections needn't be a
source of trouble.  If they are PHP users, though, and if the
site really is using PHP as you suspect, then they should probably
avoid them if your experience is an accurate reflection of the state
of the implementation of persistent connections available to PHP
users.


- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.