Re: Are many idle connections bad?

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: Craig James <cjames(at)emolecules(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Are many idle connections bad?
Date: 2015-07-30 06:28:19
Message-ID: CAFaPBrT9nH-maccER84BXG5kYV4QtY1BsrytSXCo=fXtjkgesg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sat, Jul 25, 2015 at 8:50 AM, Craig James <cjames(at)emolecules(dot)com> wrote:

> The canonical advice here is to avoid more connections than you have CPUs,
> and to use something like pg_pooler to achieve that under heavy load.
>
> We are considering using the Apache mod_perl "fast-CGI" system and perl's
> Apache::DBI module, which caches persistent connections in order to improve
> performance for lightweight web requests. Due to the way our customers are
> organized (a separate schema per client company), it's possible that there
> would be (for example) 32 fast-CGI processes, each of which had hundreds of
> cached connections open at any given time. This would result in a thousand
> or so Postgres connections on a machine with 32 CPUs.
>

I don't have any hard performance numbers, but I ditched Apache::DBI years
ago in favor of pgbouncer.

BTW if you are starting something new, my advice would be to use PSGI/Plack
instead of apache/mod_perl. Granted, you can still use apache & mod_perl
with PSGI if you want. It's more flexible in that it gives you the option
of switching to another server willy nilly. I've found Starlet and Gazelle
to be easier to work with and more performant than apache + mod_perl.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Ram N 2015-07-30 07:51:44 Performance issue with NestedLoop query
Previous Message Graeme B. Bell 2015-07-28 20:29:23 incredible surprise news from intel/micron right now...