ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholoz Koka Kiknadze" <kikna...@gmail.com>
Subject Re: [SURVEY] How many connections are in your pool?
Date Tue, 20 Jan 2009 20:12:49 GMT
Hi Sundar,

I am not an hardware expert, but I suspect that even with modern dma access
etc if you ask your CPU to process N database transactions (initiated by
different users) in parallel it may take longer compared to when you ask it
to do them consequently. So quite possible that pools with connection number
> CPU number induce performence penalties. In other words the time your pool
waits for a connection to get available in the pool is just caused by your
hardware (CPU) beeing busy, so why add extra latency with extra pool code...

Again, of course the logic can not applyed to long running transactions when
CPU is idling in the midst of transaction waiting for e.g. extra user input.

On Tue, Jan 20, 2009 at 2:50 PM, Sundar Sankar <fatboysuns@gmail.com> wrote:

> Hi Clinton,
>                   I apologize ahead, if I am missing or not getting
> something right. As far as my understanding goes, arent number of
> connections in a pool in relation to the number of parallel users that
> access the application than the number of CPU cores in a database?
>
> Regards
> S
>
>
> On Tue, Jan 20, 2009 at 12:39 PM, Clinton Begin <clinton.begin@gmail.com>wrote:
>
>> It sounds like you're still using a "pool", but your max, min, idle, and
>> active connections are all equal (i.e. 16).  Otherwise, how do you allocate
>> connections to the incoming requests?
>>
>> Cheers,
>> Clinton
>>
>>
>> On Tue, Jan 20, 2009 at 12:33 PM, Nicholoz Koka Kiknadze <
>> kiknadze@gmail.com> wrote:
>>
>>> Ours is an application that requires guaranteed response times under 50
>>> ms, so:
>>>
>>> 1) We dropped using any kind of pool, so that
>>> 2) number of constantly open connections equals to the number of
>>> processors (16)
>>>
>>> 3) I know you were asking about pool, but still I dared to respond with
>>> this no-pool variant because I think maybe what you are asking can be
>>> reformulated as: is there any use of DB pool in a short lived transaction
>>> scenario, or its better to have one connection per CPU. Testing our app made
>>> us to drop using pool with TimesTen (in memory) database. Now I started to
>>> suspect that using using db pool (I've mostly used dbcp ) in other less
>>> demanding projects (but again w/o long running transactions) was just saving
>>> development time (let pool handle concurrency issues), but not any
>>> substantial performance gain. Wonder what others think...
>>>
>>>
>>>
>>>
>>> On Tue, Jan 20, 2009 at 8:43 AM, Clinton Begin <clinton.begin@gmail.com>wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've been studying a few large enterprise applications and have noticed
>>>> an interesting trend... many of these apps have HUNDREDS of connections
>>>> (like 600) available or even open in their connection pools...
>>>>
>>>> Survey Questions:
>>>>
>>>>   1. How many connections do you have available in your pool?
>>>>   2. And if you know, how many CPU cores are available on your database
>>>> server (or cluster)?
>>>>   3. If you have 2x or 3x more connections than you do CPUs, do you have
>>>> a reason that you could share?
>>>>
>>>> Cheers,
>>>> Clinton
>>>>
>>>
>>>
>>
>

Mime
View raw message