Re: Db pool: connection management policy

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

Let's do simple one for now: pre-allocate fixed-size pool.
We'll add complex policies later.

sergey@total-knowledge.com wrote:
> It's still not perfectly clear to me what DB pool connection management
> policy we decided to implement, so I'll ask your opinions about particular
> features.
>
> How do fill in the pool?
> Should I fill it with connections up to some base number(I'm thinking 30%
> of maxCon) at UuDbPool constractor?
> Or should I do it on-the-go: start creating connections once clients
> request for them?
>
>
>   
>> 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
>>
>>     
>
>
>   

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com