pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: PFC <lists@peufeu.com>
To: Mark Stosberg <mark@summersault.com>
To: pgsql-performance@postgresql.org
Subject: Re: recommendations for web/db connection pooling or DBD::Gofer reviews
Date: Wed, 09 Apr 2008 00:40:16 +0200
Message-ID: <op.t9bc9ekpcigqcu@apollo13.peufeu.com> (raw)
In-Reply-To: <ftdpih$nid$2@ger.gmane.org>
References: <ftdpih$nid$2@ger.gmane.org>


> When traffic to our PostgreSQL-backed website spikes, the first resource
> we see being exhausted is the DB slots on the master server (currently
> set to about 400).
>
> I expect that as new Apache/mod_perl children are being put to us, they
> are creating new database connections.
>
> I'm interested in recommendations to funnel more of that traffic through
>   fewer DB slots, if that's possible. (We could also consider increasing
> the handles available, since the DB server has some CPU and memory to
> spare).
>
> I'm particularly interested in review of DBD::Gofer, which seems like it
> would help with this in our Perl application:
> http://search.cpan.org/dist/DBI/lib/DBD/Gofer.pm
>
> I realize it has limitations, like "no transactions", but I think we
> would still able to use it selectively in our application.

	Under heavy load, Apache has the usual failure mode of spawning so many  
threads/processes and database connections that it just exhausts all the  
memory on the webserver and also kills the database.
	As usual, I would use lighttpd as a frontend (also serving static files)  
to handle the large number of concurrent connections to clients, and then  
have it funnel this to a reasonable number of perl backends, something  
like 10-30. I don't know if fastcgi works with perl, but with PHP it  
certainly works very well. If you can't use fastcgi, use lighttpd as a  
HTTP proxy and apache with mod_perl behind.
	Recipe for good handling of heavy load is using an asynchronous server  
(which by design can handle any number of concurrent connections up to the  
OS' limit) in front of a small number of dynamic webpage generating  
threads/processes.



view thread (5+ messages)  latest in thread

Message-ID: <op.t9bc9ekpcigqcu@apollo13.peufeu.com>
Permalink:  ../op.t9bc9ekpcigqcu@apollo13.peufeu.com/
Also on:    postgresql.org/message-id/op.t9bc9ekpcigqcu@apollo13.peufeu.com

 · 

reply

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, mark@summersault.com
  Subject: Re: recommendations for web/db connection pooling or DBD::Gofer reviews
  In-Reply-To: <op.t9bc9ekpcigqcu@apollo13.peufeu.com>

* 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