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
