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

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

 

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)
DBCP	10	1000	251	1328863445815.00	1328863446066.00	251	0.0251
			252	1328863466569.00	1328863466821.00
			251	1328863477174.00	1328863477425.00
			254	1328863487555.00	1328863487809.00
			247	1328863499474.00	1328863499721.00
C3P0	10	1000	781	1328863372064.00	1328863372845.00	802.8	0.08028
			789	1328863385489.00	1328863386278.00
			879	1328863401335.00	1328863402214.00
			773	1328863413608.00	1328863414381.00
			792	1328863424693.00	1328863425485.00
TomcatJDBC	10	1000	191	1328863272642.00	1328863272833.00	191.8	0.01918
			197	1328863303126.00	1328863303323.00
			187	1328863313262.00	1328863313449.00
			195	1328863324253.00	1328863324448.00
			189	1328863334700.00	1328863334889.00

 

 

 

DB POOL	线程 数量	单线程 执行次数	消耗时间 (ms)	开始时间 (ms)	结束时间 (ms)	平均消耗 时间(ms)	平均单条 时间(ms)
DBCP	100	1000	786	1328862922748.00	1328862923534.00	810.4	0.008104
			853	1328862939832.00	1328862940685.00
			810	1328862955354.00	1328862956164.00
			807	1328862981344.00	1328862982151.00
			796	1328862994825.00	1328862995621.00
C3P0	100	1000	2517	1328863021884.00	1328863024401.00	2248.8	0.022488
			2340	1328863040949.00	1328863043289.00
			1968	1328863075044.00	1328863077012.00
			2256	1328863092216.00	1328863094472.00
			2163	1328863114138.00	1328863116301.00
TomcatJDBC	100	1000	752	1328863155803.00	1328863156555.00	726	0.00726
			725	1328863171617.00	1328863172342.00
			694	1328863183983.00	1328863184677.00
			703	1328863195628.00	1328863196331.00
			756	1328863209798.00	1328863210554.00

 

 

DB POOL	线程 数量	单线程 执行次数	消耗时间 (ms)	开始时间 (ms)	结束时间 (ms)	平均消耗 时间(ms)	平均单条 时间(ms)
DBCP	150	1000	1919	1328861533609.00	1328861535528.00	1854.4	0.012363
			1957	1328861551638.00	1328861553595.00
			1869	1328861746964.00	1328861748833.00
			1916	1328861791533.00	1328861793449.00
			1611	1328861832003.00	1328861833614.00
C3P0	150	1000	2726	1328861869415.00	1328861872141.00	2990.8	0.019939
			2570	1328861895349.00	1328861897919.00
			3342	1328861912351.00	1328861915693.00
			3218	1328861929664.00	1328861932882.00
			3098	1328861950163.00	1328861953261.00
TomcatJDBC	150	1000	877	1328861974599.00	1328861975476.00	861	0.00574
			821	1328861990969.00	1328861991790.00
			890	1328862016507.00	1328862017397.00
			857	1328862037077.00	1328862037934.00
			860	1328862052490.00	1328862053350.00

 

 

DB POOL	线程 数量	单线程 执行次数	消耗时间 (ms)	开始时间 (ms)	结束时间 (ms)	平均消耗 时间(ms)	平均单条 时间(ms)
DBCP	300	1000	3908	1328862516139.00	1328862520047.00	3851.8	0.012839
			3850	1328862408362.00	1328862412212.00
			3939	1328862440877.00	1328862444816.00
			3806	1328862469116.00	1328862472922.00
			3756	1328862495883.00	1328862499639.00
C3P0	300	1000	6111	1328862711585.00	1328862717696.00	6233.2	0.020777
			5162	1328862618669.00	1328862623831.00
			6261	1328862638870.00	1328862645131.00
			6832	1328862659598.00	1328862666430.00
			6800	1328862681808.00	1328862688608.00
TomcatJDBC	300	1000	3458	1328862152316.00	1328862155774.00	3403.8	0.011346
			3376	1328862308211.00	1328862311587.00
			3397	1328862227685.00	1328862231082.00
			3342	1328862261681.00	1328862265023.00
			3446	1328862358400.00	1328862361846.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

补充，刚看到的druidDatasource 测试

Changes (30)

View Page History

h1. 测试运行注意事项 
添加 -server参数 

h1. 场景一 
单线程测试，连续执行100万次，对比时间、YungGC、FullGC的情况。这个场景用于测试非激烈竞争的情况下的性能差别。 

h3. 测试代码 
svn : http://code.alibabatech.com/svn/druid/trunk/src/test/java/com/alibaba/druid/pool/benckmark/Case0.java

h3. 测试结果 
连续执行1000,000次，Druid和DBCP的测试对比结果： 
||连接池|| 时间（毫秒） || YungGC || FullGC || 

| Druid |  277  221 | 16  6 | 0 |

| DBCP |  1,647  1,606 | 70 |0|

| BoneCP | 762 | 4 |0|

h3.  测试代码  结论

{code} Druid和DBCP执行时间相差大约6倍，YungGC相差4倍多，FullGC都没有。由此看来，DruidDataSource在执行时间远胜于DBCP，而且产生的小对象比DBCP小得多。

public class Case0 extends TestCase { 

private String jdbcUrl; 
private String user; 
private String password; 
private String driverClass; 
private int initialSize = 10; 
private int minPoolSize = 1; 
private int maxPoolSize = 2; 
private int maxActive = 2; 

protected void setUp() throws Exception { 
jdbcUrl = "jdbc:fake:dragoon_v25masterdb"; 
user = "dragoon25"; 
password = "dragoon25"; 
driverClass = "com.alibaba.druid.mock.MockDriver"; 
} 

h1. 场景二 
多个线程，连续打开关闭连接1000,000次。 

public void test_0() throws Exception { 
DruidDataSource dataSource = new DruidDataSource(); 

h3. 测试代码 
http://code.alibabatech.com/svn/druid/trunk/src/test/java/com/alibaba/druid/pool/benckmark/Case1.java

h3. 测试结果 
连续执行1000,000次，Druid和DBCP的测试对比结果： 
||连接池||线程数量 ||时间（毫秒） || YungGC || FullGC || 

| Druid |2 |1,177 |  34  | 0 dataSource.setInitialSize(initialSize);  | 

| DBCP |2 |2,738 | 139 |0|
| BoneCP |2 |2,242 | 8 |0| 

| Druid |5 |3,7027 |  80  | 0 dataSource.setMaxActive(maxActive);  | 

| DBCP |5 |39,203 | 350 |0|

| Druid |10 |11,172 |  162  | 0 dataSource.setMinIdle(minPoolSize);  | 

| DBCP |10 |79,220 | 702 |0|

| Druid |20 |38,817 |  328  | 0 dataSource.setMaxIdle(maxPoolSize);  | 

dataSource.setPoolPreparedStatements(true); 
dataSource.setDriverClassName(driverClass); 
dataSource.setUrl(jdbcUrl); 
dataSource.setPoolPreparedStatements(true); 
dataSource.setUsername(user); 
dataSource.setPassword(password); 
dataSource.setValidationQuery("SELECT 1"); 
dataSource.setTestOnBorrow(true); 

| DBCP |20 |159,966 | 1402 |0|

for (int i = 0; i < 10; ++i) { 
p0(dataSource, "druid"); 
} 
System.out.println(); 
} 

h3. 结论 

2个线程时，这时候时候激烈的并发获取连接，Druid和DBCP的执行时间差距缩小了，不到3倍。

public void test_1() throws Exception { 
final BasicDataSource dataSource = new BasicDataSource(); 

5个线程时，获取连接的线程超过了maxActive（数量为2），DBCP性能急剧下降，Druid和DBCP的执行时间差距达到了13倍。

dataSource.setInitialSize(initialSize); 
dataSource.setMaxActive(maxActive); 
dataSource.setMinIdle(minPoolSize); 
dataSource.setMaxIdle(maxPoolSize); 
dataSource.setPoolPreparedStatements(true); 
dataSource.setDriverClassName(driverClass); 
dataSource.setUrl(jdbcUrl); 
dataSource.setPoolPreparedStatements(true); 
dataSource.setUsername(user); 
dataSource.setPassword(password); 
dataSource.setValidationQuery("SELECT 1"); 
dataSource.setTestOnBorrow(true); 

10个线程时，Druid和DBCP的执行时间差距拉近为7倍。

for (int i = 0; i < 10; ++i) { 
p0(dataSource, "dbcp"); 
} 
System.out.println(); 
} 

private void p0(DataSource dataSource, String name) throws SQLException { 
long startMillis = System.currentTimeMillis(); 
long startYGC = TestUtil.getYoungGC(); 
long startFullGC = TestUtil.getFullGC(); 

final int COUNT = 1000 * 1000; 
for (int i = 0; i < COUNT; ++i) { 
Connection conn = dataSource.getConnection(); 
conn.close(); 
} 
long millis = System.currentTimeMillis() - startMillis; 
long ygc = TestUtil.getYoungGC() - startYGC; 
long fullGC = TestUtil.getFullGC() - startFullGC; 

System.out.println(name + " millis : " + NumberFormat.getInstance().format(millis) + ", YGC " + ygc + " FGC " + fullGC);
} 
} 
{code}