原创文章，转载请指明出处：http://aub.iteye.com/blog/1404219， 尊重他人即尊重自己
DBCP,C3P0,Tomcat_JDBC 性能及稳定性測试
1.測试环境：
硬件环境：
数据库server：2U*8核 8G内存
測试server： 2U*8核 6G内存
软件环境：
jdk：
1.6.29
mysql：
5.0.77
mysql_driver：
mysql-connector-java-5.0.8-bin.jar
DBCP：
commons-dbcp-1.4.jar
下载地址： http://commons.apache.org/dbcp/
commons-pool-1.5.6.jar
下载地址： http://commons.apache.org/pool/
C3P0：
c3p0-0.9.1.2.jar
下载地址： http://www.mchange.com/projects/c3p0/index.html
log4j-1.2.8.jar（c3p0须要加入此包）
下载地址： http://logging.apache.org/log4j/
Tomcat_JDBC：
tomcat-jdbc.jar
下载地址： https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
或者在tomcat安装根文件夹下的lib文件夹中直接拿来用之
tomcat-juli.jar
下载地址：（没找到）
在tomcat安装根文件夹下的bin文件夹中直接拿来用之
配置信息：
数据库连接超时时间设置为： 10年
数据库支持最大连接数设置为：2000
初始化连接池大小：10
连接至最小活动线程数：10
连接池最大活动线程数：100
其它配置均保持各个连接池的默认配置
2.性能測试： （測试代码见附件）
測试点：
在多线程多任务的条件下，各个连接池获取连接然后立即关闭连接，比較所消耗的时间。
在网上看了好多关于数据库连接池方面的測试。
大多数測试过程中，包含了运行sql语句部分，即，创建连接。运行sql语句。关闭连接，
一開始我也是这样測试，
測试过过程中，发现数据非常不稳定， 这几个连接池都是忽快忽慢，
经过思考、分析，个人 认为这样是不准确的。运行sql语句时。測试已经不是数据库连接池的性能了，
全然是数据库驱动程序（比如mysql_driver ）和数据库本身的性能，
数据库连接池负责的不过建立DataSource，获取（从连接池中获取）Connection。关闭（放回到连接池）Connection，
因此，
我在測试时，没有计算初始化连接池（建立DataSource）的时间，而是连接池“获取连接然后立即关闭连接”的时间。
測试结果：
平均消耗时间是每一个用例測试了5次计算出来的
| DB POOL | 线程数量 |
单线程 运行次数 |
平均消耗 时间(ms) |
平均单条 时间(ms) |
| DBCP | 10 | 1000 | 251 | 0.0251 |
| C3P0 | 10 | 1000 | 802.8 | 0.08028 |
| TomcatJDBC | 10 | 1000 | 191.8 | 0.01918 |
| DB POOL | 线程数量 |
单线程 运行次数 |
平均消耗 时间(ms) |
平均单条 时间(ms) |
| DBCP | 100 | 1000 | 810.4 | 0.008104 |
| C3P0 | 100 | 1000 | 2248.8 | 0.022488 |
| TomcatJDBC | 100 | 1000 | 726 | 0.00726 |
| DB POOL | 线程数量 |
单线程 运行次数 |
平均消耗 时间(ms) |
平均单条 时间(ms) |
| DBCP | 150 | 1000 | 1854.4 | 0.012363 |
| C3P0 | 150 | 1000 | 2990.8 | 0.019939 |
| TomcatJDBC | 150 | 1000 | 861 | 0.00574 |
| DB POOL | 线程数量 |
单线程 运行次数 |
平均消耗 时间(ms) |
平均单条 时间(ms) |
| DBCP | 300 | 1000 | 3851.8 | 0.012839 |
| C3P0 | 300 | 1000 | 6233.2 | 0.020777 |
| TomcatJDBC | 300 | 1000 | 3403.8 | 0.011346 |
结论：
整体性能：TomcatJDBC > DBCP > C3P0
网上好多资料都说C3P0的性能要好于DBCP,从我的測试结果来看并非这样，或许是我的配置有不对的地方，
測试时最大的活动线程配置为100。
并发为150线程时，TomcatJDBC的优势明显，
也就是当并发超过连接池最大的活动线程数，但并没有超过太多的情况下，TomcatJDBC的优势明显，
当并发数为300时。3种连接池性能差距不大。
出现这样的情况，说明连接池的最大活动线程数已经不满足现有系统需求，须要调整配置了
我測试的结果都是毫秒级，
对于一个小型的系统，并发压力不大时，选择哪个连接池都没有太大区别，考虑很多其它的应该是连接池的稳定性。
3.稳定性測试： （測试代码见附件）
測试点：
1.当数据库因为未知原因关闭，又一次启动后，连接池能否够自己主动重连。无需重新启动应用服务。
2.应用服务正常，数据库服务正常，可是网络环境异常，导致连接中断。此时连接池中连接处于“半连接”状态，
现象：
在不重新启动应用服务的情况下。 mysql数据库进行重新启动操作，mysql全然重新启动后。运行程序。
TomcatJDBC和DBCP并没有自己主动重连，反复运行查询语句，会一直报异常。重新启动应用服务后恢复正常
C3P0进行了自己主动重连，反复运行查询语句，运行正常。
结论：
默认配置条件下，TomcatJDBC和DBCP并没有自己主动重连机制，查看官方文档。这缺陷能够通过改动配置解决。
另：
连接池重连机制，有2种：
1.同步验证方式：
每次获取连接或关闭连接时，运行一个提前定义的验证语句（sql语句）。
验证连接池中的连接是否有效，假设验证失败，彻底关闭此连接，
这样的方式会导致每次运行数据库操作时都有额外的开销。对性能影响较大。
2.心跳验证方式：
每隔特定的时间进行一次验证。运行一个提前定义的验证语句（sql语句），
验证连接池中的连接是否有效，假设验证失败，彻底关闭此连接，
能够依据详细情况，适当的调节验证间隔时间。
这样的方式以牺牲较小的性能开销为代价。来保持系统的稳定性。
4.心得
自从tomcat7公布以来，网络上開始出现一个新的连接池的影子，tomcat jdbc,
经过測试，发现tomcat jdbc的性能果然不错，是连接池不二的选择，
本人E文水平有限。没办法把E文翻译的那么优雅。
tomcat jdbc的其它长处，还请看它的官网介绍
https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
这篇文章具体介绍阐述dbcp与c3p0的一些不足：
Why another connection pool project
重连机制：
不推荐使用同步验证方式。
假设系统架构中。网络环境（应用服务与数据库服务之间）不稳定，硬件环境不稳定，推荐使用心跳验证方式。
假设系统架构中，网络环境和硬件环境都机器稳定。并且对数据库I/O性能要求较高时。能够不进行验证。
5.測试代码见附件：
类：TestPerformance，性能測试
类：TestStability。稳定性測试，定时运行查询语句，
类：TestWacthPool，自己主动重连測试，简单观察连接池内部状态
如有有疑问能够加我QQ: 35443224 请说明您是ITEYE 社区的朋友， ^_^
原创文章，转载请指明出处：http://aub.iteye.com/blog/1404219， 尊重他人即尊重自己