Re: [HACKERS] Simmultanous Connections (fwd)

> 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.

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.

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.

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.

> 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.
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.

> I sent her a private note saying she really probably shouldn't be looking
> at MySQL for her application, presumably having a real transaction-based
> db is a Good Thing when maintaining a database of student grades.  Told
> her she should be looking at various real RDBMS solutions and should leave
> MySQL out of the picture entirely (while also telling her I thought PG
> would work fine for her needs, of course).

That's a good summary of my intended take-home point as well, though
you said it much more clearly.  All the rest was just personal
experience that applies to our environment but my not apply to yours
or hers.

Karl