6

play フレームワークで提供される Websocket チャット サンプルでは、​​作成/使用されるアクターは 1 つだけのように思えます。また、私がよく理解していれば、アクターとスレッド間の 1:1 マッピングを強制する「受信」を使用して、このチャット サーバーを効果的にモノスレッド化しますか?

ここでコードを確認してください: https://github.com/playframework/Play20/blob/master/samples/scala/websocket-chat/app/models/ChatRoom.scala

この分析が正しければ？はいの場合、このサーバーを高度にスケーラブルにする方法についてのヒントはありますか?

4

2 に答える 2

8

この例で使用されている websocket のデフォルトのディスパッチャー構成については、 http: //www.playframework.org/documentation/2.0.1/AkkaCore に詳細がいくつかあります。

各 WebSocket 接続状態は、エージェント アクターによって管理されます。WebSocket ごとに新しいアクターが作成され、ソケットが閉じられると強制終了されます。

その Web ページには、デフォルトの構成も示されています。

websockets-dispatcher = {
  fork-join-executor {
    parallelism-factor = 1.0
    parallelism-max = 24
  }
}

デフォルトでは、すべてのディスパッチャはスレッド プールで一連のアクターを実行します。したがって、WebSocket を作成するクライアントごとに、アクターが作成されます。割り当てられるスレッドの数は、使用されるエグゼキュータ サービスによって異なります。fork-join-executorは までオンデマンドでスレッドを作成するようですparallelism-max。

その上に、アクションとプロミスを処理するアクターもいます。

akka には、パフォーマンスを微調整するための多くのノブがあるようです。http://doc.akka.io/docs/akka/2.0.1/general/configuration.htmlを参照してください。サーバーを「高度にスケーラブル」にするには、おそらく多くのベンチマークといくつかのハードウェアが必要になります。

于 2012-05-11T05:26:59.877 に答える
5

Websocket 接続にはアクター プールがありますが、ChatRoom アクターはメッセージの実際の処理を行う唯一のアクター (単一のアクター インスタンス) であり、接続/切断を管理し、この設計のボトルネックになる可能性のあるソケットのルーターのように機能します。アクターのメッセージは常に順次処理されます。このサンプルがスケーラビリティーを目的としたものではなく、WebSocket の単純なデモンストレーションであったかどうかは疑問です。

于 2012-07-12T08:45:39.623 に答える