From: Pierre C <lists@peufeu.com>
To: Matthew Wakeling <matthew@flymine.org>
To: Balkrishna Sharma <b_ki@hotmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Parallel queries for a web-application |performance testing
Date: Thu, 17 Jun 2010 13:12:22 +0200
Message-ID: <op.vefyqwfweorkce@apollo13> (raw)
In-Reply-To: <alpine.DEB.2.00.1006171032120.2534@aragorn.flymine.org>
References: <BAY149-w5365651952D598741FE4E1F0DE0@phx.gbl>
<alpine.DEB.2.00.1006171032120.2534@aragorn.flymine.org>
> When you set up a server that has high throughput requirements, the last
> thing you want to do is use it in a manner that cripples its throughput.
> Don't try and have 1000 parallel Postgres backends - it will process
> those queries slower than the optimal setup. You should aim to have
> approximately ((2 * cpu core count) + effective spindle count) number of
> backends, as that is the point at which throughput is the greatest. You
> can use pgbouncer to achieve this.
The same is true of a web server : 1000 active php interpreters (each
eating several megabytes or more) are not ideal for performance !
For php, I like lighttpd with php-fastcgi : the webserver proxies requests
to a small pool of php processes, which are only busy while generating the
page. Once the page is generated the webserver handles all (slow) IO to
the client.
An interesting side effect is that the number of database connections is
limited to the number of PHP processes in the pool, so you don't even need
a postgres connection pooler (unless you have lots of php boxes)...
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: lists@peufeu.com, matthew@flymine.org, b_ki@hotmail.com
Subject: Re: Parallel queries for a web-application |performance testing
In-Reply-To: <op.vefyqwfweorkce@apollo13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox