Bill Davidson wrote: > Christopher Schultz wrote: >>When you've played with it for a bit, tell us how things turned out. > > It's looking like optimal is caching about 40 PreparedStatement objects. > However, I should qualify that noting that it's with our application and > specifically with our little pummeling benchmark, which requests a specific > subset of services, and probably isn't even a great test of real world > traffic. > It was mainly designed to see how the app handled being heavily stressed > (like getting hit with 1000 requests at a time). > > The system is still about 3-4% slower with DBCP than with our old pooling > library. Our old pooling library did not wrap the Connection objects like > DBCP does, though it did close old Connection objects so that they only > got reused for up to two minutes at a time. I'm actually a little > surprised by > this. I would have expected that to make DBCP faster, since it keeps them > open.
The current DBCP (actually commons-pool) can struggle under very heavy load in multi-thread environments. There are plans afoot for a pool 2.0 that will be based on java.util.concurrent that should enable much better multi-threaded performance. As always, it is best to check with a profiler to see what is actually slowing you down. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
