I am no expert in this either but a default setup for oracle allows for 200 connections. At least this was the case a few version back. In my mind I think you can an maybe should have more connections than processors. Depending on the length of time the connection is open and idle. Again I could be very wrong on this so I hope others continue to input on this thread. Nathan
On Tue, Jan 20, 2009 at 2:22 PM, Sundar Sankar <fatboys...@gmail.com> wrote: > 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 >>>>>> >>>>> >>>>> >>>> >>> >> >
