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.
-S
On Tue, Jan 20, 2009 at 1:12 PM, Nicholoz Koka Kiknadze
<kikna...@gmail.com>wrote:
> 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 <fatboys...@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.be...@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 <
>>> kikna...@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.be...@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
>>>>>
>>>>
>>>>
>>>
>>
>
