Re: persistent vs. non-persistent - Mailing list pgsql-php

On Tue, 2001-10-02 at 21:21, Frank Joerdens wrote:
> On Mon, Oct 01, 2001 at 06:56:37PM -0400, Mitch Vincent wrote:
> > I'm not sure about the internal workings, I see what you mean and will await
> > your finding with great interest!
> >
> > -Mitch
>
> [ . . . ]
> > > I don't understand why apache (or PHP) doesn't see that it has a
> > persistent
> > > database connection open to use.
> > >
> > > I'm checking the PHP PGSQL extensions at this moment.
> > > More info later....
> > >
> > > Saludos.... ;-)
>
> I keep having problems too; I think because I never quite managed to
> figure out the mechanism either. Sometime last year someone mentioned
> that the php.ini parameters
>
> pgsql.max_links
> pgsql.max_persistent
>
> are meant to be understood as /per Apache child/; so if you have, say, 5
> Apache children waiting for a request, and
>
> pgsql.max_persistent = 2
>
> you could have up to 10 open connections. If an apache child which does
> not have an open connection gets a request, it will open a new
> connection, obviously. So if 4 of the 5 Apache children have open
> connections, but the 5th gets the next request, a new connection will be
> opened. I am not sure about what happens when a child which already has
> an open connection gets a new request. Hypothesis: It depends on the
> database. Say you have 3 distinct databases on your server and your
> php.ini parameter

Yes, I believe that is how it works.  For a more reasonable approach to
this problem you should look into (something like) DBBalancer (see
SourceForge for more info).

I have used persistent connections on one application and achieved a
roughly 10x speed improvement, but you need to take a few things into
consideration:

Don't quit your Apache processes too quickly.
 - To get the full benefit of a persistent connection, it needs to hang
around for a good number of requests.  Make sure Apache isn't re-
starting it's processes until they've done a thousand or so requests - I
usually set it up to around 30,000 with no problems on Linux.

Make sure you have enough RAM.
 - When things have reached some sort of 'steady state' you are likely
to have a lot of processes running.  You lose all benefit (and then
some) if you are swapping.
This could also be "Be careful about setting your maximums" because you
can control this within Apache and PostgreSQL configurations to some
extent.

But this is where DBBalancer becomes a better approach.  As a pool of
database connections, you can get the benefit of (a), while still
retaining a softer degradation under extreme demands.  The downside is
that you have to manage your transactions slightly more carefully, and
you are susceptible to memory leak problems in the database client
connection.

These are not insurmountable problems.  The upside is that DBBalancer
also lets you make a fairly smooth transition to the _next_ level, where
you have a load-balanced pool of replicated databases.

Regards,
                        Andrew.

--
--------------------------------------------------------------------
Andrew @ Catalyst .Net.NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/        PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201    MOB: +64(21)635-694    OFFICE: +64(4)499-2267