Re: persistent vs. non-persistent

In a way, it is a bit obvious because if you have a little amount of traffic
that child process for Apache are dieing frequently and not hanging around,
odds are you aren't doing enough traffic where persistent connections are
going to give you any noticeable speed improvement.

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://www.rutgersinsurance.com
----- Original Message -----
From: "Andrew McMillan" <andrew(at)catalyst(dot)net(dot)nz>
To: "Frank Joerdens" <frank(at)joerdens(dot)de>
Cc: <pgsql-php(at)postgresql(dot)org>
Sent: Tuesday, October 02, 2001 6:27 AM
Subject: Re: [PHP] persistent vs. non-persistent

> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>