Re: Pooling in Core WAS: Need help in performance tuning.

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Pooling in Core WAS: Need help in performance tuning.
Дата
Msg-id 4C3AF564.5030204@postnewspapers.com.au
обсуждение исходный текст
Ответ на Re: Pooling in Core WAS: Need help in performance tuning.  (Matthew Wakeling <matthew@flymine.org>)
Ответы Re: Pooling in Core WAS: Need help in performance tuning.  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Pooling in Core WAS: Need help in performance tuning.  (Hannu Krosing <hannu@2ndquadrant.com>)
Re: Pooling in Core WAS: Need help in performance tuning.  (Robert Haas <robertmhaas@gmail.com>)
Re: Pooling in Core WAS: Need help in performance tuning.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-performance
On 12/07/10 17:45, Matthew Wakeling wrote:
>
> I'm surprised. Doesn't apache httpd do this? Does it have to do a whole
> load of non-portable stuff? It seems to work on a whole load of platforms.

A lot of what Apache HTTPd does is handled via the Apache Portable
Runtime (APR). It contains a lot of per-platform handlers for various
functionality.

http://apr.apache.org/docs/apr/1.4/modules.html

I don't know if the socket passing is provided as part of APR or is part
of Apache HTTPd its self, but I wouldn't be at all surprised if it was
in APR.

Personally I'm now swayed by arguments presented here that trying to
push pooling into core isn't really desirable, and that better
packaging/bundling of existing solutions would be better.

Perhaps documenting the pluses/minuses of the current pooling options
and providing clear recommendations on which to use for different use
cases would help, since half the trouble is users not knowing they need
a pool or being confused as to which to select.

This discussion reminds me a bit of Hibernate's built-in client-side
connection pool. It has one, but it's a unloved stepchild that even the
Hibernate devs suggest should be avoided in favour of a couple of
external 3rd party options.

A built-in pool seems like a great idea, but there are multiple existing
ones because they solve different problems in different ways. Unless a
built-in one could solve ALL those needs, or be so vastly simpler (due
to code re-use, easier configuration, etc) that it's worth building one
that won't fit everyone's needs, then it's best to stick to the existing
external options.

So rather than asking "should core have a connection pool" perhaps
what's needed is to ask "what can an in-core pool do that an external
pool cannot do?"

Admission control / resource limit features would be great to have in
core, and can't really be done fully in external modules ... but could
be designed in ways that would allow external poolers to add
functionality on top. Josh Berkus has made some good points on why this
isn't as easy as it looks, though:


http://it.toolbox.com/blogs/database-soup/admission-control-and-its-discontents-39895

--
Craig Ringer

В списке pgsql-performance по дате отправления:

Предыдущее
От: Matthew Wakeling
Дата:
Сообщение: Re: Pooling in Core WAS: Need help in performance tuning.
Следующее
От:
Дата:
Сообщение: now() gives same time within the session