DBCP,C3P0,Tomcat_JDBC 性能及稳定性测试



DBCP,C3P0,Tomcat_JDBC 性能及稳定性测试

1.测试环境：  

硬件环境：

数据库服务器：2U*8核 8G内存 
测试服务器：   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) DBCP1010002510.0251C3P0101000802.80.08028TomcatJDBC101000191.80.01918

 

DB POOL 线程数量 单线程
执行次数 平均消耗
时间(ms)平均单条
时间(ms) DBCP1001000810.40.008104C3P010010002248.80.022488TomcatJDBC10010007260.00726

 

DB POOL 线程数量 单线程
执行次数 平均消耗
时间(ms)平均单条
时间(ms) DBCP15010001854.40.012363C3P015010002990.80.019939TomcatJDBC15010008610.00574

 

DB POOL 线程数量 单线程
执行次数 平均消耗
时间(ms)平均单条
时间(ms) DBCP30010003851.80.012839C3P030010006233.20.020777TomcatJDBC30010003403.80.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性能要求较高时，可以不进行验证。

本文出自 “AUB” 博客，请务必保留此出处http://aubdiy.blog.51cto.com/2978849/815796

代码请见http://download.csdn.net/detail/mkj414370365/7937839