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

原创文章，转载请指明出处：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， 尊重他人即尊重自己