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 >
