实际应用连接池性能测试比hikari要低

imhun commented 4 years ago

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结果：

Chris2018998 commented 4 years ago

非常感谢您提供jmeter的测试报告，这里有一个新版本（未放入maven中心）

https://github.com/Chris2018998/BeeCP/blob/master/doc/temp/beecp-2.6.0.jar

加班中，具体原因稍晚点告知。

Chris2018998 commented 4 years ago

个人未使用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

能想的到原因大致有这些吧

imhun commented 4 years ago

测试了32满池的场景，有个问题，连接池第一次启动比较慢，需要15s：测试结果最大延迟下降很多，平均延迟变化不大