Re: Are many idle connections bad?

Поиск
Список
Период
Сортировка
От Alex Hunsaker
Тема Re: Are many idle connections bad?
Дата
Msg-id CAFaPBrT9nH-maccER84BXG5kYV4QtY1BsrytSXCo=fXtjkgesg@mail.gmail.com
обсуждение исходный текст
Ответ на Are many idle connections bad?  (Craig James <cjames@emolecules.com>)
Список 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 по дате отправления:

Предыдущее
От: "Graeme B. Bell"
Дата:
Сообщение: incredible surprise news from intel/micron right now...
Следующее
От: Ram N
Дата:
Сообщение: Performance issue with NestedLoop query