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

From Craig James
Subject Are many idle connections bad?
Date
Msg-id CAFwQ8rcnqy4F4zDg+UX0A5dLbJ=4ifCDk7WN21y7w5HLtYxo7w@mail.gmail.com
Whole thread Raw
Responses Re: Are many idle connections bad?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Are many idle connections bad?  (Jeff Janes <jeff.janes@gmail.com>)
Re: Are many idle connections bad?  (Alex Hunsaker <badalex@gmail.com>)
List pgsql-performance
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.

But, Apache's fast-CGI mechanism allows you to specify the maximum number of fast-CGI processes that can run at one time; requests are queue by the Apache server if the load exceeds this maximum. That means that there would never be more than a configured maximum number of active connections; the rest would be idle.

So we'd have a situation where there there could be thousands of connections, but the actual workload would be throttled to any limit we like. We'd almost certainly limit it to match the number of CPUs.

So the question is: do idle connections impact performance?

Thanks,
Craig

pgsql-performance by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: hyperthreadin low performance
Next
From: Tom Lane
Date:
Subject: Re: Are many idle connections bad?