UniverseUniversity


Home Projects Jobs Clientele Contact

uu


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Db pool: connection management policy



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
>



Authoright © Total Knowledge: 2001-2008