On Fri, Jun 29, 2001 at 03:15:15PM -0400, some SMTP stream spewed forth:
> On Friday 29 June 2001 02:01, Ron Chmara wrote:
>
> > Some tips on using PG/PHP/Apache in a high-dollar business environment:
>
> > 7. If you're on linux, recompile/adjust your kernel for massive
> > shm/sem space. Otherwise, you'll run out of backends when apache
> > needs 'em. the pg_pconnect php function needs a backend for each
> > apache process. 50 apache processes? 50 postmaster backends.
> > (One way around this: set your MaxRequest counter low to "rotate
> > the pool")
>
> What if you have several databases? Does the maximum number of connections
> need to be the mximum number of httpd processes TIMES the number of
> databases? ouch.
Not exactly.
Pretend the following:
You have 3 database users (usernames) using persistent connections.
In the simplest case, you need 3 PostgreSQL backends to support one each
of those users. That means you need 3 backends per httpd process.
10 concurrent httpd clients => 30 PostgreSQL backends.
Yep, ouch. In an extreme case, you might want to check out AOLServer for
its pooling stuff. Technically, you only need enough ram to support the
maximum number of concurrent backends -- 10 httpd process -> 10 backends,
because (in most cases) you will have one user connecting from each
httpd. There would be some severe overhead when excavating them from
swap, though.
> If so, does Linux's way of dealing with multiple processes using the same
> code mean that even if you do have hundreds of simultaneous DB connections,
> it won't necessarily use an exorbitant amount of memory?
gh
