performance - Akka 什么时候会带来更好的性能？

Question

我刚刚使用 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。

我尝试过的调整:

将池actor分成多个，每个都持有所有真实连接的一部分

调整一些默认调度程序配置参数(吞吐量、并行度)

但没有看到明显的改善。

我的问题是:

这是使用 akka 将获得更好性能的合适用例吗？

如果是，我怎样才能获得与那些手工线程连接池实现类似或更好的基准数据？

如果不是，为什么？是否有任何既定标准可以帮助我做出决定何时使用akka ?

Answer 1

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