プレイフレームワークで提供されているWebsocketチャットサンプルでは、1人の俳優しか作成/使用されていないようです。また、私はよく理解すれば、アクターとスレッドの間に1：1マッピングを強制し、効果的にこのチャットサーバーをモノスレッド化する「受信」を使用しますか？Play Websocketサンプル - Akkaアクターは1人だけですか？
この分析が正しい場合は？はいの場合、このサーバーのスケーラビリティを高める方法についての指針はありますか？
その例で使用されているのWebSocketのデフォルトのディスパッチャの設定のhttp://www.playframework.org/documentation/2.0.1/AkkaCoreでいくつかの詳細があります。
各WebSocket接続状態は、エージェントアクタによって管理されます。 WebSocketごとに新しいアクターが作成され、ソケットが閉じられると殺されます。
websockets-dispatcher = { fork-join-executor { parallelism-factor = 1.0 parallelism-max = 24 } }は、デフォルトではすべてのディスパッチャは、スレッドプールに俳優の彼らのセットを実行します：Webページは、デフォルトの設定が表示されていることを
。したがって、各クライアントがwebsocketを作成するために、アクターが作成されます。割り当てられるスレッドの数は、使用されるエグゼキュータ・サービスによって異なります。 まで、fork-join-executorは要求に応じてスレッドを作成するようです。
さらに、アクションと約束を処理するアクターもいます。
性能を微調整するために、アッカには多くのノブがあるようです。 http://doc.akka.io/docs/akka/2.0.1/general/configuration.htmlを参照してください。サーバのスケーラビリティを高めるには、ベンチマークやハードウェアが必要になるでしょう。
websocket接続にはアクタープールがありますが、実際にメッセージを処理し、接続/切断を管理し、ボトルネックになる可能性のあるソケットのルータとして機能するのは、ChatRoomアクタだけですメッセージは常にアクタのために順番に処理されるため、この設計ではサンプルがスケーラビリティを目的としているのかどうかは疑問ですが、ウェブソケットのデモは簡単です。