Re: Scaling postgres - Mailing list pgsql-general

I think you mean pg_connect(); with pg_pconnect() the connection is always
there till you close the connection manually with pg_close();

as well pg_connect() is only open till the script has finshed exacuting.


----- Original Message -----
From: "Benjamin Smith" <bens@effortlessis.com>
To: <pgsql-general@postgresql.org>
Sent: Saturday, April 13, 2002 4:40 PM
Subject: Re: [GENERAL] 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>