So all this being said what is the general rule of thumb for setting up pool sizes?
On Tue, Jan 20, 2009 at 5:43 PM, Nathan Maves <nathan.ma...@gmail.com> wrote: > 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 >>>>>> >>>>> >>>> >>> >> > > -- Rick
