实际应用连接池性能测试比hikari要低
imhun opened this issue · comments
spring boot 2.3,oracle 12数据库
beecp版本：2.5.4..2
hikari版本:3.4.5
jdk:11
测试语句：select 1 from dual;
jmeter通过http请求应用api进行压测，
2种负载情况下，beecp都比hikari的结果要差一些，这个跟beecp官方给出的测试结果有所不同，请问可能是什么原因导致的呢？
测试数据如下：
连接池：10，50并发用户
beecp结果：
hikari结果：
连接池：32，100并发用户
beecp结果：
hikari结果：
非常感谢您提供jmeter的测试报告，这里有一个新版本（未放入maven中心）
https://github.com/Chris2018998/BeeCP/blob/master/doc/temp/beecp-2.6.0.jar
加班中，具体原因稍晚点告知。
个人未使用Jmeter做过测试，介绍中说明是基于光连接池的性能测试。
原因1：小蜜蜂连接池增加了一个安全关闭锁，应用场景
池中有一个定时线程用于识别：被借走但又长时间不活动的链接，强制进行关闭或回收，在定时间线程关闭时刻点上，借用者线程可能也会出发关闭活动，实际上借用者线程的关闭只是将代理对像标记为关闭，并将物理连接归还到中池中去，连接池会把这个放释放的连接推送给等待者（如果存在）。考虑这个关闭点上可能存在同步性，因此增加了同步锁，同一时刻点，只能有一个线程会成功关闭连接，其他都失败（要是多个成功，是很危险的行为）
不清楚光连接是否有这样的安全策略
原因2：最近活动时间类型为：volatile类型（光连接池是非volatile）
volatile变量保持线程之间的可见性，连接在活动时候，会将活动时刻点（毫秒）写入最近活动时间变量中，那么定时扫描线程能读取到连接的准确活动时间，从而帮助定时线程做出是否需要强制关闭活动准确判断，那么对volatile的写入耗时要比非volatile变量更耗时一些
原因3：执行的代码量比光连接池多，为什么要多呢，希望在不违背正确性的前提下，让性能更高一点。
光连接池的代码做的非常精简，很多时候几乎是由代理类直接调用物理对像，在大多的数的情况下，是没有问题的，但是这样有考虑过特例情况吗？最近在重新回顾学习Mysql驱动实现，发现ServerCace模式（LurCache)下的ServerPreparedStatement是直接从LurCache取得（remove)，并直接返回给使用者，而这个ServerPreparedStatement在使用完毕后，只是标记为关闭，并放入Cache中，突然联想起网上很多有介绍说光连接池在Mysql的ServerCache模式下，性能更高，于是做了一些测试，发现可能存在的一些问题。
1： 已经关闭的PreparedStatement居然可以复活？（https://my.oschina.net/u/3918073/blog/4645061）
（对于已经关闭的代理对象再次调用，起码抛个异常也好）
2： PreparedStatement关闭后，ResultSet居然可以继续使用（https://my.oschina.net/u/3918073/blog/4649929）
3： 对于Statement.getResultSet()的一点理解（https://my.oschina.net/u/3918073/blog/4649962）
如果光连接池加上这些。。。。。。（个人对连接池的代码认识停留在17年）
原因4：光连接池在默认的情况下，初始化时候会创建一个连接，第一次创建的连接时会慢一点，后面请求的时候再创建的时，速度加快，小蜜蜂连接池是完全在请求时候才会去创建的，这样情况下，显然是慢人一拍
原因5：光连连池增补连接应该是通过线程池的方式做的，小蜜蜂连接池是单线程的方式增加，因此如果初始化数从0开始的话，
那么这个是要稍慢一些，如果请求次数不多的情况下，类似人排队一样，前面的请求者耗时长，会导致整个队伍都延迟一些。后面也可以考虑调整为使用线程池的方式增补。测试是在满池的情况的进行的？ 比如连接池的最大值是10，那么初始值也设置为10
能想的到原因大致有这些吧
测试了32满池的场景，有个问题，连接池第一次启动比较慢，需要15s：
测试结果最大延迟下降很多，平均延迟变化不大
还有个问题，关闭应用的时候，有个关闭连接池的报错
好的，感谢您的反馈，我尽快排查问题
我本地做了一次Jmeter测试（Marridb）
10个连接 50个线程 1000次循环
取连接对比
SQL查询对比
启动耗时
启动100个连接
1：那个异常的问题，我本地修复了，重新测试没有发现
2：启动耗时过多，会不会与机器网络有关？
我用的数据库是远程数据库，网络性能一般，不过hikari没有问题，启动连接池很快
连接池数32，100线程，循环1000次
启动慢的问题，我的环境中没有模拟出来，后面多观察一段时间。
找了台Oracle11g机器，用Jmeter测试一下了（32连接*100线程，循环1000次）
取连接
查询
从测试情况来看，Bee略高一点点
新包：
https://github.com/Chris2018998/BeeCP/blob/master/doc/temp/beecp-3.0.0.jar
能否请您帮忙以新包再测试一次？ 麻烦了
最新的3.0.1，用了本地的mysql8数据库，上面是beecp，下面是hikari，吞吐量差不多了
