On Mon, Jan 28, 2002 at 02:19:57PM -0500, Frank Bax wrote:
> The connection will only be reused if the *same* apache child process
> handles the request.
IMHO, also if another apache child handles the request which also has a
connection open to the same database using the same connection string.
[ . . . ]
> If your postgres database is on the same server as you webserver, there is
> neglible gains for using pconnect over connect.
Not exactly true, I think. A while ago I started a thread about using
Unix sockets vs. TCP sockets because I had trouble getting Unix sockets
to work on Solaris. It emerged from the discussion that the added
overhead vis-a-vis local sockets of going through the TCP/IP stack was
completely negligible compared to all the other stuff that is going on
when making, or reusing, a (persistent or non-persistent) db connection.
I should think that with a fast, non-saturated network, the fact that
you then add a physical (e.g. Ethernet) layer to the scenario would not
matter much either. I recently split webserver and db server here
(basically to make administration less of a headache because I had
Postgres servers running on 2 different boxes, for Intranet and
Internet), and put the databases from the Postgres server running on the
webserver (an old Dual PPro 200) onto a somewhat newer, 2nd box (Dual
PII 400). It makes quite a difference, speed-wise, which would support
my line of reasoning. I didn't try to measure this scientifically (or
pseudo-scientifically, for that matter).
Whether you get a performance gain from using pconnect over connect
depends on whether you use simple queries (connection overhead is large
compared to query execution time) or complex queries (connection
overhead is small compared to query execution time). It has little to
do, IMHO, with whether you go throug local sockets or TCP/IP sockets, or
if your Postgres server is on the same physical machine as your
webserver.
Regards, Frank