9

我刚刚使用 Akka 编写了一个 JDBC 连接池。

它使用一个actor来保存真实数据库连接的“maxPoolSize”集合。调用者向池参与者请求连接并接收 aFuture[Connection]并且连接的状态变为“忙碌”,直到调用者将其返回到池 on connection.close。如果所有连接都忙,则新传入的连接请求将被放置在等待队列中(也由池参与者持有)。稍后当连接返回时,等待请求将被满足。

这个逻辑的实现在akka中很简单,就几十行代码。然而,当使用 BoneCP多线程测试来测试性能时(即调用者在返回close时立即连接。基准所有请求和结果),我发现 Akka 版本比许多其他连接池实现慢比如tomcat-jdbc、BoneCP甚至commons DBCP。Future[Connection]getConnectiontraversedcloseAwaitFuture

我尝试过的调整:

  1. 将池actor分成多个,每个都包含所有真实连接的一部分
  2. 调整一些默认调度程序配置参数(吞吐量、并行度)

但没有看到明显的改善。

我的问题是:

  1. 这是使用 akka 将获得更好性能的合适用例吗?
  2. 如果是,我怎样才能获得与那些手工线程连接池实现类似或更好的基准数据?
  3. 如果不是,为什么?是否有任何既定标准可以帮助我决定何时使用 akka
4

3 回答 3

3

要回答问题 #1,这不是 Akka 在速度方面表现出色的用例。您基本上已经解决了一个问题,该问题通常通过针对多个读取器和写入器优化的并发数据结构来解决,并通过单个参与者对其进行序列化。

于 2013-10-01T13:47:49.207 回答
0

另一种方法是创建Router,它将生成多个从 Actor,每个从 Actor 代表一个连接。

但请注意,可能存在潜在的竞争条件。

另外,您使用的是什么版本的 Scala 和 Akka?

于 2013-10-01T10:33:39.710 回答
0

Akka 可能是高度并行计算的好选择,而 JDBC 连接池不是高度并行计算的好例子。

于 2014-06-11T15:41:55.707 回答