Re: Scaling postgres

AFAIK, connections aren't linked to clients per se, but rather to active
connections in PHP4, Using pg_pconnect in PHP4, connections are recycled
after a client's page hit is finished, so it's available for the next page
hit.

Meaning, to service 800 simultaneous users with 10% active saturation, you'd
have active 80 DB connections - something an appropriately configured server
should handle easily.

BTW - 10% active connections is high.Those 800 people would have to be
working it pretty darn hard to get numbers like that. My experience would be
more like (tops) 2-5%. In most circumstances, 1/2 or more of the wait from
click to view on a web hit is download/render time on the client, not the
web server.

-Ben

----- Original Message -----
From: Nigel J. Andrews <nandrews@investsystems.co.uk>
To: <pgsql-general@postgresql.org>
Sent: Saturday, April 13, 2002 4:30 PM
Subject: Re: [GENERAL] Scaling postgres


>
> On Sat, 13 Apr 2002, Steve Lane wrote:
>
> > On 4/13/02 5:10 PM, "Neil Conway" <nconway@klamath.dyndns.org> wrote:
> >
> > > On Sat, 13 Apr 2002 17:00:19 -0500
> > > "Steve Lane" <slane@fmpro.com> wrote:
> > >> On the front end, as I understand it (I know this is not really
> > >> Postgres-specific), with Apache and mod_php I need one process per
> > >> concurrent user. Anyone care to speculate how many concurrent users I
could
> > >> get on a single box? I really don't know what's reasonable to expect.
> > >
> > > For the front-end, it totally depends on the hardware you're using,
> > > the OS you're running this on, and the design/performance requirements
> > > of your application. For example, a good caching layer could easily
> > > improve performance by 100% or more.
> >
> > I'm less concerned with performance (at the moment) than concurrency. My
> > worry is that (lacking a multithreaded web server, which Apache 2.0
appears
> > to give me), I need to have 800-1200 processes, one per connection,
running
> > on the web server or servers. I don't know if that's feasible under any
> > circumstances.
>
> It's not something I've done but I don't see why not if the OS is
configured
> with appropiate limits on processes, open file descriptors etc.
>
> >  [snip]
> >
> > >> On the back end, is there any direct relationship between the number
of open
> > >> client connections and the number of processes used?
> > >
> > > Yes, there is 1 postgres process per database connection. Whether
> > > you create 1 database connection per client would depend on how you
> > > design your application.
> >
> > Can you clarify that second sentence a bit? I wasn't aware I had much
choice
> > -- meaning that, since Apache 1.x + PHP is not multithreaded and does
not do
> > connection pooling, I think I'm stuck with one database connection per
> > front-side client connection.
>
> He means each frontend process opens one and only one connection to the
> DB. Since it is possible for an application to open more than one
connection
> and the relationship is one to one for the number of connections to
backend
> processes (plus the postmaster, stats. etc) it is possible to have a one
> application process to many backend processes arrangement.
>
>
> --
> Nigel J. Andrews
> Director
>
> ---
> Logictree Systems Limited
> Computer Consultants
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster