Re: Are many idle connections bad? - Mailing list pgsql-performance

From Alex Hunsaker
Subject Re: Are many idle connections bad?
Date
Msg-id CAFaPBrT9nH-maccER84BXG5kYV4QtY1BsrytSXCo=fXtjkgesg@mail.gmail.com
Whole thread Raw
In response to Are many idle connections bad?  (Craig James <cjames@emolecules.com>)
List pgsql-performance


On Sat, Jul 25, 2015 at 8:50 AM, Craig James <cjames@emolecules.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.

pgsql-performance by date:

Previous
From: "Graeme B. Bell"
Date:
Subject: incredible surprise news from intel/micron right now...
Next
From: Ram N
Date:
Subject: Performance issue with NestedLoop query