9

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

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

このロジックの実装は、akka では非常に簡単で、数十行のコードしかありません。ただし、BoneCPマルチスレッド テストを使用してパフォーマンスをテストすると (つまり、呼び出し元は、返されcloseた接続が満たされるとすぐに接続します。すべての要求と結果のベンチマーク)、Akka バージョンは他の多くの接続プールの実装よりも遅いことがわかりました。 tomcat-jdbc、BoneCP、さらにはコモンズ DBCP など。Future[Connection]getConnectiontraversedcloseAwaitFuture

私がチューニングのために試したこと：

  1. プール アクターを複数のアクターに分割し、それぞれがすべての実際の接続の一部を保持します
  2. default-dispatcher 設定パラメータの一部を微調整 (スループット、並列処理)

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

私の質問は:

  1. これは、akka を使用するとパフォーマンスが向上する適切なユース ケースですか?
  2. そうである場合、これらの手作りのスレッド接続プールの実装と同様またはより優れたベンチマーク データを取得するにはどうすればよいでしょうか?
  3. そうでない場合、なぜですか？akka をいつ使用するかを決定するのに役立つ確立された基準はありますか?
4

3 に答える 3

3

質問 1 に答えるために、これは Akka が速度で優れているユース ケースではありません。基本的に、複数のリーダーとライター用に最適化された並行データ構造で通常解決される問題を取り上げ、単一のアクターを介してそれをシリアル化しました。

于 2013-10-01T13:47:49.207 に答える
0

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

ただし、潜在的な競合状態が発生する可能性があることに注意してください。

また、使用している Scala と Akka のバージョンは何ですか?

于 2013-10-01T10:33:39.710 に答える