Play Websocket sample - Only one Akka actor?

Question

In the Websocket chat sample provided with the play framework, it seems to me that only one actor is ever created/used; Also it uses "receive" which if I understood well, force the 1:1 mapping between an actor and a thread, effectively making this chat server mono-threaded ?

Check the code here: https://github.com/playframework/Play20/blob/master/samples/scala/websocket-chat/app/models/ChatRoom.scala

If this analysis correct? If yes, do you have pointers on how this server could be made highly scalable?

Answer 1

There are some details at http://www.playframework.org/documentation/2.0.1/AkkaCore on the default dispatcher configuration for websockets which are used in that example.

Each WebSocket connection state is managed by an Agent actor. A new actor is created for each WebSocket, and is killed when the socket is closed.

That web page also shows the default configuration:

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

By default all dispatchers will run their set of actors on a thread pool. So for each client creating a websocket, an actor will be created. How many threads are allocated depends on which executor service is used. It seems the fork-join-executor will create threads on demand up to parallelism-max .

On top of that there are also actors to process actions and promises.

There seem to be many knobs in akka to fine tune performance. See http://doc.akka.io/docs/akka/2.0.1/general/configuration.html . Making a server "highly scalable" will probably involve lots of benchmarking and some hardware.

Answer 2

Although the websocket connections will have an actor pool but still the ChatRoom Actor is the only one ( single actor instance ) doing the actual processing with messages, managing connects/disconnects and acting like a router for sockets which may be the bottleneck for this design as the messages are always processed sequentially for an actor. I doubt if the sample was meant for scalability but rather a simple demonstration for websockets.