Re: apache-php-postgresql connection question\ - Mailing list pgsql-php

On Thu, 31 Jan 2002, Frank Bax wrote:

> At 12:11 PM 1/31/02 -0700, tom.kemp@philips.com wrote:
> >Also, if I do a persistent connection, it appears that PHP will try to
> >use this connection if it exists, prior to creating a new persistent
> >connection, right?  Well, does it only reuse the already connected
> >persistent if it is the same user?  How does this work?  Does it check
> >that it is the same user/password (does my script have to supply this
> >in the second persistent connection function) prior to using the
> >preexisting connection? Is it tied to the current browser request?
>
> We've talked a lot about pg_pconnect this week; I'll try to summarise what
> we've learned...
>
> Each browser request from client is handled by an apache child process on
> server.  Apache uses multiple child processes running concurrently to
> handle these browser requests.
>
> pg_pconnect will reuse a previously created connection to the database if
> the previous connection was made within the same apache child process *and*
> the connect string is "identical" (same host, database, username, password).
>     http://www.php.net/manual/en/features.persistent-connections.php
> Using pg_pconnect() over pg_connect() may not always be a huge saving.
> Persistant connections are typically desired if your database server is a
> separate box from your webserver.  If these servers are in the same box,
> and query execution time is dominate factor on your system, then there is
> minimal saving with pg_pconnect over pg_connect.  If you have simple, very
> fast queries, then TCP connect and fork/exec (of the postgres backends)
> overhead may dominate and pg_pconnect wins again.

Of course, we're optimizing for time, here.  pconnect has a BIG overhead:
it increases the memory footprint of your application a lot. You see
it on the host which is running postgresql, of course. So use pconnect()
if you've got RAM to spare (and on a large DB server, RAM is never enough).
What I mean here is that it's never a win, it's always a tradeoff.

> If you support many different connect strings, then there is another factor
> to consider.  You should expect to see many postgres client connections
> running on your server:
> A) Number of unique connect strings used.
> B) Number of active apache child processes.
>
> Multiply A*B to get max number of possible concurrent connections on your
> system (max_connections in postgresql.conf).  If A*B can go over postgres
> connection limit, then you might start getting connection refused messages;
> in which case you might consider pg_connect.  Otherwise, you move security
> code into your php scripts and use a single username for database access.
>
> Frank
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

.TM.
--
      ____/  ____/   /
     /      /       /            Marco Colombo
    ___/  ___  /   /              Technical Manager
   /          /   /             ESI s.r.l.
 _____/ _____/  _/               Colombo@ESI.it