[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Db pool: connection management policy
That is somehow similar to the strategy I've already offered. It doesn't matter for us (unless we exhausted the server resources or reached some hard limit) how many connections are in the pool. It does matter to have a certain amount of ready to use connections.
2007/3/29, sergey@total-knowledge.com <sergey@total-knowledge.com>:
I feel like an expert in DB pools now, so here is another strategy that
used in DB pools called overflow.
If application is experiencing heavy load and ithe pool is maxed out, the
pool will try to take some extra overflow connections.
If a client requests a connection, but there are no available connections,
then the pool will create a brand new connection and return it to the
client.
When connection is released, the pool checks if load is still heavy. If
yes, then the pool will return this overflow connection to be reused. If
load is not that high any more, then the overflow connection is closed and
not being returned to the pool.
> There are many possible approaches to this. Using dynamic sizing,
> with some minimum and maximum numbers of connections is one of them,
> hard-set pre-allocated pool is another one. Alexey's proposal (connections
> are pre-allocated, but never used more then once) is yet another approach.
> All of them have their place, and which policy we chose depends on
> specifics of the application and use patterns.
> In the ideal case, we should be able to chose which policy to use, either
> at
> compile time, or at run time.
>
> sergey@total-knowledge.com wrote:
>> Some thoughts regarding a pool size.
>>
>> At this point, initially we are going to fill in our pool with
>> connections
>> to certain number (let's say due to unusual activity the max of
>> connections in the pool once reached 90 with maxCon=100). Let's say an
>> average load for our pool is 50, so those 40 extra connections is the
>> waste of space and DB resources).
>> We may need to shrink the pool to around 50 connections. In order to do
>> that we need to have another parameter - "idle time" after which the
>> connection will be closed and removed from the m_connections.
>> Do you guys think it's something useful?
>>
>>
>
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
>
>
--
Alexey Parshin,
http://www.sptk.net