Re: Scaling postgres - Mailing list pgsql-general
From | Benjamin Smith |
---|---|
Subject | Re: Scaling postgres |
Date | |
Msg-id | 002201c1e344$967f7020$0afefe0a@benjamindsmith.com Whole thread Raw |
In response to | Re: Scaling postgres ("Nigel J. Andrews" <nandrews@investsystems.co.uk>) |
List | pgsql-general |
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
pgsql-general by date: