我刚刚使用 Akka 编写了一个 JDBC 连接池。
它使用一个actor来保存真实数据库连接的“maxPoolSize”集合。调用者向池参与者请求连接并收到 Future[Connection]
并且连接的状态变为“忙碌”,直到调用者将其返回到池中 connection.close
.如果所有连接都忙,则新传入的连接请求将被放置在等待队列中(也由池参与者持有)。稍后当连接返回时,等待请求将被满足。
这个逻辑的实现在akka中很简单,就几十行代码。然而,当使用 BoneCP Multithread Test测试性能(即调用者 close
当 Future[Connection]
返回的 getConnection
被满足时立即连接。基准 traversed
所有 close
请求和 Await
的结果 Future
),我发现 Akka 版本比许多其他连接池实现慢,例如 tomcat-jdbc、BoneCP 甚至是 commons DBCP。
我尝试过的调整:
但没有看到明显的改善。
我的问题是:
最佳答案
要回答问题 #1,这不是 Akka 在速度方面表现出色的用例。您基本上已经解决了一个问题,该问题通常通过针对多个读取器和写入器优化的并发数据结构来解决,并通过单个参与者对其进行序列化。
关于performance - Akka 什么时候会带来更好的性能?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18940034/