ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sundar Sankar" <fatboys...@gmail.com>
Subject Re: [SURVEY] How many connections are in your pool?
Date Tue, 20 Jan 2009 21:22:09 GMT
Thanks Nicholoz!
                                I have never ever questioned people for
having so many connections. But that was the reason what I have always got,
i.e,  Connections being propotionate to number of parallel users. I just
brought the question about because, I wasnt surprised at all when Clinton
mentioned 600 connections in the pool.


On Tue, Jan 20, 2009 at 1:12 PM, Nicholoz Koka Kiknadze

> 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

View raw message