zoukankan      html  css  js  c++  java
  • 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.0251
    2521328863466569.001328863466821.00
    2511328863477174.001328863477425.00
    2541328863487555.001328863487809.00
    2471328863499474.001328863499721.00
    C3P01010007811328863372064.001328863372845.00802.80.08028
    7891328863385489.001328863386278.00
    8791328863401335.001328863402214.00
    7731328863413608.001328863414381.00
    7921328863424693.001328863425485.00
    TomcatJDBC1010001911328863272642.001328863272833.00191.80.01918
    1971328863303126.001328863303323.00
    1871328863313262.001328863313449.00
    1951328863324253.001328863324448.00
    1891328863334700.001328863334889.00

     

     

     

    DB POOL线程
    数量
    单线程
    执行次数
    消耗时间
    (ms)
    开始时间
    (ms)
    结束时间
    (ms)
    平均消耗
    时间(ms)
    平均单条
    时间(ms)
    DBCP10010007861328862922748.001328862923534.00810.40.008104
    8531328862939832.001328862940685.00
    8101328862955354.001328862956164.00
    8071328862981344.001328862982151.00
    7961328862994825.001328862995621.00
    C3P0100100025171328863021884.001328863024401.002248.80.022488
    23401328863040949.001328863043289.00
    19681328863075044.001328863077012.00
    22561328863092216.001328863094472.00
    21631328863114138.001328863116301.00
    TomcatJDBC10010007521328863155803.001328863156555.007260.00726
    7251328863171617.001328863172342.00
    6941328863183983.001328863184677.00
    7031328863195628.001328863196331.00
    7561328863209798.001328863210554.00

     

     

    DB POOL线程
    数量
    单线程
    执行次数
    消耗时间
    (ms)
    开始时间
    (ms)
    结束时间
    (ms)
    平均消耗
    时间(ms)
    平均单条
    时间(ms)
    DBCP150100019191328861533609.001328861535528.001854.40.012363
    19571328861551638.001328861553595.00
    18691328861746964.001328861748833.00
    19161328861791533.001328861793449.00
    16111328861832003.001328861833614.00
    C3P0150100027261328861869415.001328861872141.002990.80.019939
    25701328861895349.001328861897919.00
    33421328861912351.001328861915693.00
    32181328861929664.001328861932882.00
    30981328861950163.001328861953261.00
    TomcatJDBC15010008771328861974599.001328861975476.008610.00574
    8211328861990969.001328861991790.00
    8901328862016507.001328862017397.00
    8571328862037077.001328862037934.00
    8601328862052490.001328862053350.00

     

     

    DB POOL线程
    数量
    单线程
    执行次数
    消耗时间
    (ms)
    开始时间
    (ms)
    结束时间
    (ms)
    平均消耗
    时间(ms)
    平均单条
    时间(ms)
    DBCP300100039081328862516139.001328862520047.003851.80.012839
    38501328862408362.001328862412212.00
    39391328862440877.001328862444816.00
    38061328862469116.001328862472922.00
    37561328862495883.001328862499639.00
    C3P0300100061111328862711585.001328862717696.006233.20.020777
    51621328862618669.001328862623831.00
    62611328862638870.001328862645131.00
    68321328862659598.001328862666430.00
    68001328862681808.001328862688608.00
    TomcatJDBC300100034581328862152316.001328862155774.003403.80.011346
    33761328862308211.001328862311587.00
    33971328862227685.001328862231082.00
    33421328862261681.001328862265023.00
    34461328862358400.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
  • 相关阅读:
    mysql 实战 or、in与union all 的查询效率
    转:手机流畅的决定性因素
    合批只是对CPU的优化,与GPU没有任何关系
    UNITY 打包时提示sdk tools 或 sdk build tools版本低时可以直接点update 按钮进行更新
    RGB ECT 4BIT 压缩后质量远高于RGB ETC2 4BIT
    Adreno GPU Profiler
    UNITY2018.3 在editor下运行时new memoryprofiler显示 shader占用内存很大的问题在安卓上并没有看到
    VS2017断点调试UNITY2018.3 经常卡住的问题
    一次UNITY闪退问题的定位心得
    UNITY2018 真机开启deepprofiling的操作
  • 原文地址:https://www.cnblogs.com/xmanblue/p/5589555.html
Copyright © 2011-2022 走看看