Akkaはいつより良いパフォーマンスをもたらしますか？

Question

私はAkkaを使用してJDBC接続プールを作成しました。

アクタを使用して、実際のデータベース接続の「maxPoolSize」コレクションを保持します。呼び出し元はプールアクターに接続を要求し、Future[Connection]を受信し、呼び出し元がconnection.closeにプールに戻すまで接続のステータスは「ビジー」になります。すべての接続がビジー状態の場合、新しい着信接続要求は待機キューに格納されます（プールアクタによっても保持されます）。後で接続が返されると、待機中の要求が満たされます。

このロジックの実装はakkaで非常に簡単です。数十行のコードだけです。 （getConnectionによって返さFuture[Connection]が満たされたとき。すぐすなわち、発信者closeベンチマークtraversedすべてclose要求し、その結果FutureためAwaitを接続する）の性能をテストするためにBoneCP Multithread Testを使用している場合しかし、私は、アッカのバージョンが遅くなることがわかりましたtomcat-jdbc、BoneCP、COMMON DBCPなどの他の多くの接続プールの実装よりも優れています。私は、チューニングのために試してみました何

：複数のものをそれぞれにプールの俳優を分割

1. はデフォルトのディスパッチャ設定パラメータ（スループット、並列処理）の一部を微調整するすべての実の接続
2. の一部を保持

しかし顕著な改善は見られませんでした。

私の質問は：

1. これはアッカを使用すると、より良いパフォーマンスを得ることを、適切な使用事例ですか？
2. もしそうなら、どうすれば手作りスレッド接続プールの実装よりも似たような、あるいはより良いベンチマークデータを得ることができますか？
3. そうでない場合、なぜですか？決定するのに役立つ確立された基準がありますかakkaをいつ使用するのですか？

Answer 1

もう1つの方法は、Routerを作成して、複数のスレーブアクターがそれぞれ1つの接続を表すようにすることです。

ただし競合の可能性があることに注意してください。

ScalaとAkkaのどのバージョンを使用していますか？

Answer 2

質問1に答えるには、Akkaがスピードに優れているユースケースではありません。基本的には、複数の読者とライターに最適化された並行データ構造で解決され、単一のアクターでシリアライズされた問題を解決しました。

Answer 3

高度な並列計算にはAkkaが適していますが、並列接続にはJDBC接続プールは適していません。