Play Websocket Beispiel - Nur ein Akka Schauspieler?

Question

In dem Websocket-Chat-Beispiel, das mit dem Play-Framework bereitgestellt wird, scheint mir, dass nur ein Schauspieler jemals erstellt/verwendet wird; Außerdem verwendet es "receive", was, wenn ich es gut verstanden habe, die 1: 1-Zuordnung zwischen einem Akteur und einem Thread erzwingt, wodurch dieser Chat-Server tatsächlich mono-threaded wird?

Überprüfen Sie den Code hier: https://github.com/playframework/Play20/blob/master/samples/scala/websocket-chat/app/models/ChatRoom.scala

Wenn diese Analyse richtig? Wenn ja, haben Sie Hinweise, wie dieser Server hochgradig skalierbar gemacht werden könnte?

Answer 1

Es gibt einige Details unter http://www.playframework.org/documentation/2.0.1/AkkaCore in der Standard-Dispatcher-Konfiguration für Websockets, die in diesem Beispiel verwendet werden.

Jeder WebSocket-Verbindungsstatus wird von einem Agent-Aktor verwaltet. Ein neuer Akteur wird für jeden WebSocket erstellt und wird beendet, wenn der Socket geschlossen wird.

Diese Web-Seite auch die Standardkonfiguration zeigt:

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

Standardmäßig werden alle Disponenten ihre Reihe von Akteuren auf einem Thread-Pool laufen. Für jeden Kunden, der einen Websocket erstellt, wird also ein Schauspieler erstellt. Wie viele Threads zugewiesen werden, hängt davon ab, welcher Executor-Dienst verwendet wird. Es scheint, dass die fork-join-executor Threads bei Bedarf bis zu parallelism-max erstellen wird.

Darüber hinaus gibt es auch Akteure, um Aktionen und Versprechen zu verarbeiten.

Es scheint viele Knöpfe in akka zu geben, um die Leistung zu optimieren. Siehe http://doc.akka.io/docs/akka/2.0.1/general/configuration.html. Um einen Server "hochgradig skalierbar" zu machen, werden wahrscheinlich viele Benchmarks und einige Hardware benötigt.

Answer 2

Obwohl die Websocket-Verbindungen einen Actor-Pool haben, ist der ChatRoom-Actor der einzige (Einzelactor-Instanz), der die eigentliche Verarbeitung mit Nachrichten durchführt, Verbindungen herstellt/trennt und wie ein Router für Sockets agiert für dieses Design, da die Nachrichten immer nacheinander für einen Akteur verarbeitet werden. Ich bezweifle, dass die Probe für Skalierbarkeit gedacht war, sondern eher eine einfache Demonstration für Websockets.