建站网站关键词优化,联通最低套餐,线下推广有哪几种渠道,食品网站建设方案线程池实现填充短信在最近几个月中#xff0c;我们一直看到很小但持续的操作失败#xff0c;但有一个奇怪的异常– org.springframework.jdbc.CannotGetJdbcConnectionException –“无法获得JDBC连接#xff1b; 嵌套异常是java.sql.SQLException#xff1a;客户端尝试检出… 线程池实现填充短信 在最近几个月中我们一直看到很小但持续的操作失败但有一个奇怪的异常– org.springframework.jdbc.CannotGetJdbcConnectionException –“无法获得JDBC连接 嵌套异常是java.sql.SQLException客户端尝试检出Connection的尝试已超时。 ” 我们的自然假设是我们在C3P0连接池中存在某种争用尝试获取连接的客户端必须等待该争用可用。 我们最好的猜测是正是这种争执导致了超时。 因此当然我们要做的第一件事是增加连接池中的最大连接数。 但是无论我们将限制设置得多么高它都无济于事。 然后我们尝试更改连接的超时参数。 那没有产生任何更好的结果。 此时情报已经确定下来并且由于猜测似乎没有用因此我们决定进行测量。 使用连接池上的一个简单包装器我们看到即使连接池中有空闲连接我们仍然会得到签出超时。 调查连接池开销 为了研究连接池的开销我们执行了一个基准测试该基准测试由6个回合组成每个回合包括20,000个SQL操作读/写比为1:10使用20个线程和20个连接的连接池来执行。 使用具有20个连接的池使用20个线程意味着资源连接上没有争用。 因此任何开销都是由连接池本身引起的。 我们忽略了第一次预热运行的结果而取了随后5次运行的统计数据。 从这些数据中我们收集连接签出时间连接释放时间和总池开销。 基准项目代码可以在以下位置找到 https : //github.com/yoavaa/connection-pool-benchmark 我们测试了3个不同的连接池 C3P0 – com.mchangec3p00.9.5-pre3 – C3P0DataSourceBenchmark类 Bone CP – com.jolboxbonecp0.8.0-rc1 –类BoneDataSourceBenchmark Apache DBCP – commons-dbcpcommons-dbcp1.4 –类DbcpDataSourceBenchmark 在该项目中还有一个我自己的实验性异步池的基准测试-https: //github.com/yoavaa/async-connection-pool 。但是出于本文的目的我将忽略它。 为了自己运行基准测试您应该使用下表设置MySQL CREATE TABLE item (file_name varchar(100) NOT NULL,user_guid varchar(50) NOT NULL,media_type varchar(16) NOT NULL,date_created datetime NOT NULL,date_updated timestamp AUTO_INCREMENT NOT NULL DEFAULT CURRENT_TIMESTAMP,PRIMARY KEY(file_name)
) 然后更新Credentials对象以指向此MySQL安装。 运行基准测试时结果示例如下 run, param, total time, errors, under 1000 nSec,1000 nSec - 3200 nSec,3200 nSec - 10 µSec,10 µSec - 32 µSec,32 µSec - 100 µSec,100 µSec - 320 µSec,320 µSec - 1000 µSec,1000 µSec - 3200 µSec,3200 µSec - 10 mSec,10 mSec - 32 mSec,32 mSec - 100 mSec,100 mSec - 320 mSec,320 mSec - 1000 mSec,1000 mSec - 3200 mSec,other
0, acquire,29587,0,0,5,1625,8132,738,660,1332,1787,2062,2048,1430,181,0,0,0
0, execution, , ,0,0,0,0,0,0,0,1848,6566,6456,5078,52,0,0,0
0, release, , ,0,8,6416,9848,3110,68,77,115,124,148,75,11,0,0,0
0, overhead, , ,0,0,49,4573,5459,711,1399,1812,2142,2157,1498,200,0,0,0
1, acquire,27941,0,0,125,8153,499,658,829,1588,2255,2470,2377,1013,33,0,0,0
1, execution, , ,0,0,0,0,0,0,6,1730,6105,6768,5368,23,0,0,0
1, release, , ,0,49,15722,3733,55,42,69,91,123,101,14,1,0,0,0
1, overhead, , ,0,0,2497,5819,869,830,1610,2303,2545,2448,1042,37,0,0,0 此信息已导入Excel文件也包含在基准项目中以进行分析。 C3P0 最初在C3P0中我们在生产环境中看到了原始异常。 让我们看看它如何执行 阅读图表 前三个图表获取发布开销是基于性能的存储桶图表。 Y轴表示在一定时间范围内完成的操作数在X轴上显示。 默认的经验法则是左侧的条形越高效果越好。 第四个图表是瀑布图其中每个水平线表示一个DB操作。 棕色表示等待获取连接的时间绿色表示执行数据库操作的时间蓝色表示将连接返回到连接池的时间。 从图表中可以看出通常C3P0在3.2-10微秒内获得连接并在3.2-10微秒内释放连接。 那绝对是一些令人印象深刻的表现。 但是C3P0在约3.2-32毫秒处还有另一个峰值而长尾巴则高达320-1000毫秒。 正是第二个高峰导致了我们的例外。 C3P0怎么了 是什么原因导致了这种极小但相当大的超长操作百分比而大多数时候却表现惊人 纵观4 个图可以为我们指出了答案的方向。 第4 个图表从左上角到右下角都有一条清晰的对角线表明总体上连接获取是按顺序开始的。 但是我们可以识别出一些奇怪的东西–我们可以看到棕色的三角形表示当多个线程试图获取连接时第一个线程比后续线程等待更多时间的情况。 这转化为用于获取连接的两个性能“组”。 一些线程极其快速地获得连接而有些线程则饿死等待连接而较后的线程的请求则得到了较早的答复。 早期线程比后续线程等待更长的时间的这种行为意味着不公平的同步。 事实上挖掘到C3P0代码时我们已经看到了收购的连接的过程中C3P0使用“ 同步 ”关键字三次。 在Java中 synceded 关键字创建了不公平的锁这可能导致线程饥饿。 稍后我们可能会尝试使用公平锁定来修补C3P0。 如果这样做我们自然会分享我们的发现。 此基准测试的C3P0配置 最小泳池大小20 初始池大小20 游泳池的最大大小20 采集增量10 辅助线程数6 骨CP 我们在Wix上尝试了BoneCP但结果不一因此目前尚不确定我们是否喜欢它。 尽管分析并不全面但我们将BoneCP基准测试的结果包括在这些帖子中。 查看图表我们可以看到Bone的连接捕获性能非常出色–大多数操作在3.2微秒内完成比C3P0快得多。 但是我们还观察到连接释放时间很长大约1-10毫秒太高了。 我们还观察到Bone的操作很长开销高达320毫秒。 从数据来看在正常和“极端”情况下BoneCP似乎都比C3P0好。 但是如图表所示差异并不大。 查看第4 个图表我们看到与C3P0相比褐色较少因为连接获取更好但出现了蓝线表明线程等待连接释放的时间。 如上所述由于我们对使用BoneCP充其量是矛盾的因此我们没有投入大量资源来分析此连接池的性能问题。 Apache DBCP Apache DBCP被称为古老的数据源。 让我们看看与其他两个相比的情况如何。 显而易见的是– DBCP性能优于C3P0和Bone。 在所有方面无论是在连接签出时间连接释放时间还是瀑布图形式方面它都优于其他方法。 那么您应该使用什么数据源 好吧这是一个不平凡的问题。 显然就连接池性能而言我们显然是赢家– DBCP。 似乎C3P0应该很容易修复我们可以尝试一下。 但是重要的是要记住此研究的范围仅限于实际连接获取/释放的性能。 实际的数据源选择是一个更复杂的问题。 例如该基准测试忽略了一些重要方面例如池的增长和缩小网络错误的处理数据库故障时的故障转移等等。 参考 填充一个池需要多少个线程 来自我们的JCG合作伙伴 Yoav Abrahami来自Wix IO博客。 翻译自: https://www.javacodegeeks.com/2013/06/how-many-threads-does-it-take-to-fill-a-pool.html线程池实现填充短信
