Comparison of the use of several common database connection pools
The most primitive database use is to open a connection and use it. After use, be sure to close the connection to release resources. Due to the frequent opening and closing of connections,
there is a certain resource load on the jvm including the database, especially when the application pressure is high, the resource occupation is more likely to cause performance problems. From this, the effect of using the connection pool is revealed. His principle is actually not complicated:
first open a certain number of database connections, allocate them to the caller when they are used, and return them to the connection pool after the call is completed. Pay attention to these after returning to the connection pool. The connection is not closed, but is
ready to be allocated to the next caller. From this, it can be seen that the connection pool saves a lot of database connection opening and closing actions, which is self-evident to improve system performance.
Several concepts:
minimum connections - the number of connections opened immediately after the application starts and the minimum number of subsequent connections maintained.
The maximum number of connections--the maximum number of connections that the application can use The number of
connection growth--the number of new connections opened by the application each time
An example illustrates the operation of the connection pool:
Assuming that the minimum and maximum connections are set to 10 and 20, then once the application starts, it will first open 10 database connections, but note that the number in use of the database connection pool at this time is 0--because you are not using these connections, and idle The number is 10. Then you start to log in, assuming that the login code uses a connection to query, then the database connection pool's in-use number is 1 and the idle number is 9. This does not require opening a connection from the database - because the connection pool is ready. 10 for you. The login is over, what is the current number of connections in the connection pool? Of course it is 0, because that connection has been returned to the connection pool with the end of the transaction. Then 11 people log in at the same time at the same time, what will happen: the connection pool applies (opens) a new connection from the database, and sends it together with the other 10. The number of connections used in this instant connection pool is 11, but it doesn't matter Under normal circumstances, it will become 0 after a while. What if 21 people are logged in at the same time? The 21st person can only wait for the person in front to release the connection to him after logging in. At this time, the connection pool has opened 20 database connections-although it is likely that the number of database connections in use has dropped to 0, will 20 connections be maintained? Of course not, the connection pool will close a certain amount of connections within a certain period of time and return it to the database. In this example, the number is 20-10=10, because only the minimum number of connections needs to be maintained, and this time period is also in the connection pool. configured.
Well, the basic concepts are over, let's get down to business and compare.
First of all, in order to facilitate the portability and configurability of the application, it is recommended to use jndi to configure the connection pool uniformly. There are actually many examples on how to configure it.
Here is a simple example (using the spring framework):
first, configure the jndi name in the context definition of the application, such as a resource.xml file, which is written as
<bean id="dataSource" class= "org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName"><value>jdbc/myapp</value></property>
</bean>
注意dataSource这个bean在dao层(hibernate或jdbc)的配置文件里需要作为dataSource名称的属性配置到所有bean中
其中“jdbc/myds”这个就是jndi名称了，下一步就是在应用服务器连接池里进行数据库连接以及对应的jndi配置了
一 开源数据连接池
1 dbcp
dbcp可能是使用最多的开源连接池，原因大概是因为配置方便，而且很多开源和tomcat应用例子都是使用的这个连接池吧。
这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。这个连接池的配置参见附件压缩包中的:dbcp.xml
使用评价：在具体项目应用中，发现此连接池的持续运行的稳定性还是可以，不过速度稍慢，在大并发量的压力下稳定性
有所下降，此外不提供连接池监控
2 c3p0
c3p0是另外一个开源的连接池，在业界也是比较有名的，这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。
这个连接池的配置参见附件压缩包中的:c3p0.xml。
使用评价：在具体项目应用中，发现此连接池的持续运行的稳定性相当不错，在大并发量的压力下稳定性也有一定保证，
此外不提供连接池监控。
3 proxool
proxool这个连接池可能用到的人比较少，但也有一定知名度，这个连接池可以设置最大和最小连接，连接等待时间等，基本功能都有。
这个连接池的配置参见附件压缩包中的：proxool.xml。
使用评价：在具体项目应用中，发现此连接池的持续运行的稳定性有一定问题，有一个需要长时间跑批的任务场景任务，同样的代码
在另外2个开源连接池中成功结束，但在proxool中出现异常退出。
但是proxool有一个优势--连接池监控，这是个很诱人的东西，大概的配置方式就是在web.xml中添加如下定义：
<servlet>
<servlet-name>admin</servlet-name>
<servlet-class>org.logicalcobwebs.proxool.admin.servlet.AdminServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>admin</servlet-name>
<url-pattern>/admin</url-pattern>
</servlet-mapping>
并在应用启动后访问：http://localhost:8080/myapp/admin这个url即可监控
不过proxool本身的包在监测使用中会有编码问题，附件中有一个
解决此问题的包，参见附件压缩包中的：proxool-0.9.0RC3.jar。另外需要jdk1.5以上的环境。
总结时刻：
综上所述，这几种开源连接池各有优劣，推荐使用c3p0，经检验这种连接池性能稳定，承压能力强。而proxool尽管有明显的性能问题，
但由于它具备监控功能，因此建议在开发测试时使用，有助于确定是否有连接没有被关掉，可以排除一些代码的性能问题。
二 商业中间件连接池
上面列举了几种开源的连接池，其实可以肯定的说，如果条件允许使用weblogic和websphere等中间件，那么不要犹豫，一定要
使用这些商业级别的中间件所自带的数据库连接池，他们的性能以及调配和开源的不在一个量级，举个例子，曾经有一个项目，数据量比较大，同样的代码应用，在3种开源的连接池里都多少出现过系统异常，而weblogic和websphere的连接池则正常运行，当然后来发现代码有一定瑕疵，但也侧面说明了商业连接池的强大。
1 weblogic的连接池
weblogic 8 是一个让人使用起来很轻松方便的应用服务器软件，但是到了9简直就是折磨，不知道是bea是怎么想的，oracle收购了bea以后出了10，比9强不少，但是最喜欢的还是8。。。
题外话不说了，就以8.1版本介绍一下他的数据库连接池（其实10的配置也差不多）
首先是连接池的基本设置，这个不讲了，网上有很多教程。然后进入Data Sources菜单配置数据源里边的JNDI Name，要和之前在应用配置中的一致：jdbc/myapp。
然后是连接池一些具体项目的配置，包括设置最小（Initial Capacity），最大（ Maximum Capacity）连接，以及
每次连接增加时需要一次性增加多少连接（Capacity Increment）。Allow Shrinking（是否把不用的连接退还数据库以保持最小连接数--这个就可以参见之前的连接池阐述的例子进行理解了）。
另外还有几个有意思的选项Test Reserved Connections：对取得的连接进行测试，Test Released Connections：对释放的连接进行测试。有人会问了，这个有什么用啊？
不知道大家在项目中有没有遇到java报连接失效的异常，反正我碰到过，只有在系统压力大的时候才出现。而有了这个选项就不用担心这个问题了--因为连接池已经帮你测试了，一旦检查到连接是无效的他会废弃掉还给数据库，只给你有效的。不过这个连接失效的异常其实多半是应用的不严谨造成的，我们更因该关心应代码的问题--但起码weblogic想到帮你弥补一下，是不是很贴心：）
另外一个重要功能当然是连接池监控：monitor选项卡里可以看到使用情况，有人又要问了，没有什么指标啊，别忘了custom view这个功能链接哦：）
有以下指标：当前连接数、曾经达到的峰值、可以使用的连接数、等待的连接数、从数据库打开的连接数、曾经关闭的连接数。。。其中前3项是我最关注的
使用评价：在具体项目应用中，此连接池的持续运行的稳定性很强，在大并发量的压力下性能也相当优秀，另外在一些异常情况下连接池里的连接也能够及时释放。
连接池监控一目了然，及时到位。
2 websphere的连接池
还是先来段题外话：记得有人说过，websphere只有版本6以后才算是websphere，个人很赞同。websphere 5以及以前的版本。。。还是忘了吧。
其实websphere的连接池秉承ibm一贯的风格：功能强大，使用复杂：）
进入控制台使用“JDBC提供程序”功能菜单进行连接池的基本配置，一路下来，不同的数据库配置方式不尽相同，最奇怪的是还要单独手工加上user和password参数，如果没有
资料指导的话还真是摸不着头脑。这些基本设置还是网上找吧很多的。连接池设置完还需要设置数据源，jndi名字一样与之前的对应：jdbc/myapp
高级设置包括初始化连接数，最大连接，连接有效性检查，不使用超时。。其实这些都和weblogic中的连接池配置大致一样。
连接池监控：使用运行监控菜单，里边会有一个监控项目选择，选jdbc监控即可，可恶的是一开始弹出什么服务器操作系统需要安装什么图形化控件，选择是那么就得去找到控件在操作系统（linux）下安装，然后很多的依赖组件都没有。。。搞了半天才发现选择否，监控数据以及图形一样能出来嘛，真是要怒了。
虽然经过一番波折但是监控的内容还是很强大的，就连接池来说一样包括当前连接数、曾经达到的峰值、可以使用的连接数、从数据库打开的连接数、曾经关闭的连接数。。。其中前3项是我最关注的，比较奇怪的现象是应用刚启动的时候已开启的连接数量竟然没有达到初始定义的连接数量，不清楚websphere是怎么个计算机制。
另外在压力大的时候可使用的连接数会是负数，当时很奇怪，想想也了然了，那个负数肯定是排队等待的数量了
使用评价：在具体项目应用中，此连接池的持续运行的稳定性相当强，在大并发量的压力下性能也足够优秀，另外在一些异常情况下连接池里的连接能够及时释放，
连接池监控配置有些复杂，但是配置好后各项指标一目了然并且有图形显示
总结时刻：
这两种商业级别的连接池都给我留下深刻印象，功能强大，使用稳定，性能优秀，监控到位。可以说难分伯仲，相对而言weblogic的连接池使用配置和监控配置更简单明了，而websphere的更复杂但选项功能也更多一些。其实这正是对两种应用服务器的使用印象的直接反映，当然总体比较2种应用服务器应该又是另一个话题了，也许在下一期的内容里。。。
比较了多种连接池的优劣，下面这个话题可能和比较本身没有直接关系，但个人认为应该是更有价值的一些经验分享吧，那就是---这么多指标配置，那些最大和最小连接数以及其他一些必要的配置指标，在一个正式的生产项目中到底应该配置什么值呢？
其实这个值首先还是要根据具体的项目情况、数据规模以及并发数来制定的(尽管像是套话，但是我们研发人员严谨的作风还是必要的:)。具体而言在中型偏小型的项目--给个数值把，用户数300到3000，数据量100万到1亿---中,建议weblogic设置为最大和最小都是200，websphere最小200最大300，前提是2者设置的最小内存要在1G以上，当然如果条件允许内存越大越好，不过32位机内存1.5G的限制是一定的（64位嘛我愿意设个4G内存过来，速度提升的感觉很爽啊）。这个数字出来以后相信会有不少问题要抛过来，我一一谈一下自己的体验和想法吧
1 为什么是200或300而不是更高？
回答： 再分配多了效果也不大了，一个是应用服务器维持这个连接数需要内存支持，刚才说了32位的机器只能支持到1.5G，并且维护大量的连接进行分配使用对cpu也是一个不小的负荷，因此不宜太大。
2 为什么不小一点？
回答： 如果太小，那么在上述规模项目的并发量以及数据量上来以后会造成排队现象，系统会变慢，数据库连接会经常打开和关闭，性能上有压力，用户体验也不好。
3 为什么weblogic最小最大都一样，而websphere不一样
回答： 其实和分配内存的最小最大值的情况一样，一般都推荐2个值应该一致，都放在内存里就好了嘛。但是ibm官方推荐2个值要有区别---官方说法还是要听的
4 其他开源连接池的分配方案还没说呢？
回答： 开源的个人认为到100就可以了，再高他也不会太稳定，当然1G的最小内存是一定要给tomcat分的
5 还有其他的指标吗？
回答： 当然还有一些，但个人认为剩下的具体情况具体分析了不在这里一一列举了，大家有兴趣可以和我讨论分享一下。
林林总总说了不少希望对大家有帮助，这些比较分析和数据都具备实际应用支撑。
last:
Druid数据库连接池使用:
阿里巴巴推出的国产数据库连接池，据网上测试对比，比目前的DBCP或C3P0数据库连接池性能更好
简单使用介绍
Druid与其他数据库连接池使用方法基本一样（与DBCP非常相似），将数据库的连接信息全部配置给DataSource对象
下面给出2种配置方法实例：
1. 纯Java代码创建
dataSource = new DruidDataSource();dataSource.setDriverClassName("com.mysql.jdbc.Driver");dataSource.setUsername("root");dataSource.setPassword("11111111");dataSource.setUrl("jdbc:mysql://127.0.0.1:3306/jspdemo");dataSource.setInitialSize(5);dataSource.setMinIdle(1);dataSource.setMaxActive(10); // 启用监控统计功能 dataSource.setFilters("stat");// for mysql dataSource.setPoolPreparedStatements(false);
2. 基于Spring创建
<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close"> <!-- 基本属性 url、user、password --> <property name="url" value="${jdbc_url}" /> <property name="username" value="${jdbc_user}" /> <property name="password" value="${jdbc_password}" /> <!-- 配置初始化大小、最小、最大 --> <property name="initialSize" value="1" /> <property name="minIdle" value="1" /> <property name="maxActive" value="20" /> <!-- 配置获取连接等待超时的时间 --> <property name="maxWait" value="60000" /> <!-- 配置间隔多久才进行一次检测，检测需要关闭的空闲连接，单位是毫秒 --> <property name="timeBetweenEvictionRunsMillis" value="60000" /> <!-- 配置一个连接在池中最小生存的时间，单位是毫秒 --> <property name="minEvictableIdleTimeMillis" value="300000" /> <property name="validationQuery" value="SELECT 'x'" /> <property name="testWhileIdle" value="true" /> <property name="testOnBorrow" value="false" /> <property name="testOnReturn" value="false" /> <!-- 打开PSCache，并且指定每个连接上PSCache的大小 --> <property name="poolPreparedStatements" value="true" /> <property name="maxPoolPreparedStatementPerConnectionSize" value="20" /> <!-- 配置监控统计拦截的filters --> <property name="filters" value="stat" /> </bean>启用Web监控统计功能需要在Web应用的web.xml中加入这个Servlet声明
<servlet> <servlet-name>DruidStatView</servlet-name> <servlet-class>com.alibaba.druid.support.http.StatViewServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>DruidStatView</servlet-name> <url-pattern>/druid/*</url-pattern> <servlet-mapping>通过 http://ip:port/druid/ 地址访问即可
项目地址
https://github.com/AlibabaTech/druid/wiki