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

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）的时间，而是连接池“获取连接然后马上关闭连接”的时间。

 

测试结果：

 

 

DB POOL线程
数量单线程
执行次数消耗时间
(ms)开始时间
(ms)结束时间
(ms)平均消耗
时间(ms)平均单条
时间(ms)DBCP1010002511328863445815.001328863446066.002510.02512521328863466569.001328863466821.002511328863477174.001328863477425.002541328863487555.001328863487809.002471328863499474.001328863499721.00C3P01010007811328863372064.001328863372845.00802.80.080287891328863385489.001328863386278.008791328863401335.001328863402214.007731328863413608.001328863414381.007921328863424693.001328863425485.00TomcatJDBC1010001911328863272642.001328863272833.00191.80.019181971328863303126.001328863303323.001871328863313262.001328863313449.001951328863324253.001328863324448.001891328863334700.001328863334889.00

 

 

 

DB POOL线程
数量单线程
执行次数消耗时间
(ms)开始时间
(ms)结束时间
(ms)平均消耗
时间(ms)平均单条
时间(ms)DBCP10010007861328862922748.001328862923534.00810.40.0081048531328862939832.001328862940685.008101328862955354.001328862956164.008071328862981344.001328862982151.007961328862994825.001328862995621.00C3P0100100025171328863021884.001328863024401.002248.80.02248823401328863040949.001328863043289.0019681328863075044.001328863077012.0022561328863092216.001328863094472.0021631328863114138.001328863116301.00TomcatJDBC10010007521328863155803.001328863156555.007260.007267251328863171617.001328863172342.006941328863183983.001328863184677.007031328863195628.001328863196331.007561328863209798.001328863210554.00

 

 

DB POOL线程
数量单线程
执行次数消耗时间
(ms)开始时间
(ms)结束时间
(ms)平均消耗
时间(ms)平均单条
时间(ms)DBCP150100019191328861533609.001328861535528.001854.40.01236319571328861551638.001328861553595.0018691328861746964.001328861748833.0019161328861791533.001328861793449.0016111328861832003.001328861833614.00C3P0150100027261328861869415.001328861872141.002990.80.01993925701328861895349.001328861897919.0033421328861912351.001328861915693.0032181328861929664.001328861932882.0030981328861950163.001328861953261.00TomcatJDBC15010008771328861974599.001328861975476.008610.005748211328861990969.001328861991790.008901328862016507.001328862017397.008571328862037077.001328862037934.008601328862052490.001328862053350.00

 

 

DB POOL线程
数量单线程
执行次数消耗时间
(ms)开始时间
(ms)结束时间
(ms)平均消耗
时间(ms)平均单条
时间(ms)DBCP300100039081328862516139.001328862520047.003851.80.01283938501328862408362.001328862412212.0039391328862440877.001328862444816.0038061328862469116.001328862472922.0037561328862495883.001328862499639.00C3P0300100061111328862711585.001328862717696.006233.20.02077751621328862618669.001328862623831.0062611328862638870.001328862645131.0068321328862659598.001328862666430.0068001328862681808.001328862688608.00TomcatJDBC300100034581328862152316.001328862155774.003403.80.01134633761328862308211.001328862311587.0033971328862227685.001328862231082.0033421328862261681.001328862265023.0034461328862358400.001328862361846.00

 

结论：

总体性能：TomcatJDBC > DBCP > C3P0

网上好多资料都说C3P0的性能要好于DBCP,从我的测试结果来看并不是这样，也许是我的配置有不正确的地方，

 

测试时最大的活动线程配置为100，并发为150线程时，TomcatJDBC的优势明显，

也就是当并发超过连接池最大的活动线程数，但并没有超过太多的情况下，TomcatJDBC的优势明显，

 

我测试的结果都是毫秒级，

对于一个小型的系统，并发压力不大时，选择哪个连接池都没有太大差别，考虑更多的应该是连接池的稳定性。

 

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性能要求较高时，可以不进行验证。

转自：http://aub.iteye.com/blog/1404219