Thinking behind decision of database connection pool size

If a typical request spends 50% of its time doing calculations and 50% on database connectivity you might only need 50 connections in your pool. Of course your application should release the db connection as early as possible.

In general holding a connection is not expensive for a database (while creating a new one is quite expensive). It should be no problem to keep the size high enough.

You can set

• maximum pool size to 100
• preferred pool size to 50
• and the idle timeout to 5 minutes for pooled connections.

I am not familiar with microsoft sql server but I think its max pool limit is 100

Tomcat will be fine with this number of pool size.

Beware that the pool may cost memory for nothing if unused. The pool configuration highly depends on where your bottleneck is:

CPU, memory, disc, network, complex database queries, high concurrency, ... many of these ?

Default pool size is often 5 up to 10. First make sure you have a problem with the database. Try extremes like 2 or 30 under artificial load and see how it behaves. I think the links provided by @vlad-mihalcea are quite interesting.

You should evaluate the application's concurrency requirement, the database operation time, and also the how many connections the server(or db vender) can support.

So 100 users don't means you need a connection pool with size 100.

Sizing a connection pool is not a trivial thing to do. You basically need:

• metrics to investigate the connection usage
• failover mechanisms for when there is no connection available

FlexyPool aims to aid you in figuring out the right connection pool size.