Re: Connection pooling - Number of connections

Guillaume Smet wrote
> Brett Wooldridge, the creator of HikariCP [1] - a high performance
> Java connection pool - is contemplating the idea to change the way
> pooling is done in HikariCP and have a fixed-size pool of connections
> always open.
>
> No maxPoolSize, no minIdle, no minPoolSize, juste a poolSize parameter
> which sets the size of the pool. At application startup, all the
> connections are opened and maintained by the pool throughout the life
> of the application.
>
> The basic idea is that if you decide that your application might need
> 100 connections at time, you set poolSize to 100 and HikariCP
> maintains 100 connections open.
>
> I recall very old posts on this list where people were talking about
> code paths sensitive to the number of connections open (or even
> max_connections) and that it wasn't such a good idea to keep
> connections open if they were not really needed.
>
> As a lot of scalability work has been done since this (very old) time,
> I was wondering if it was still the rule of thumb or if the idea of
> Brett to completely simplify the connection management is the way to
> go.
>
> It seems that at least another pool implementation is going this way
> so I thought it might be a good idea to have the opinion of the
> database side of things. This way, it will be easier to take a well
> informed decision.

The developer, not the pool implementer, is going to ultimately decide which
trade-offs to incur.  Having a connection open, even if idle, consumes
resources and performance no matter how minimal.

Pool management does cost cycles as well so if one does not need pool
management then getting rid of it is probably worthwhile to them.  The
question is whether you want to only meet the need of this specific user or
whether you want to provide them with flexibility.

If existing pool management implementations are reasonably well implemented
and efficient then focusing effort on a potentially under-served use-case
definitely has merit.

Consider this train-of-thought:  no matter how large the pool size if you
are constantly keeping, say, 90% of the connections actively working then
having, on average, 10% of the connections sitting idle is probably not
going to be noticeable on the server and the reduction in overhead of
managing a pool is typically a net positive.  Now, I had no clue what
percentage is actually true, or under what conditions and pool sizes it may
vary, but that is a calculation that someone deciding on between managed and
un-managed pools would need to make.

David J.




--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Connection-pooling-Number-of-connections-tp5797025p5797030.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.