在播放框架提供的 Websocket 聊天示例中,在我看来,只有一个演员被创建/使用过;它还使用“接收”,如果我理解得很好,它会强制执行角色和线程之间的 1:1 映射,从而有效地使该聊天服务器成为单线程?
如果这个分析正确?如果是,您是否有关于如何使该服务器具有高度可扩展性的指示?
在播放框架提供的 Websocket 聊天示例中,在我看来,只有一个演员被创建/使用过;它还使用“接收”,如果我理解得很好,它会强制执行角色和线程之间的 1:1 映射,从而有效地使该聊天服务器成为单线程?
如果这个分析正确?如果是,您是否有关于如何使该服务器具有高度可扩展性的指示?
在http://www.playframework.org/documentation/2.0.1/AkkaCore有一些关于该示例中使用的 websocket 的默认调度程序配置的详细信息。
每个 WebSocket 连接状态都由一个 Agent Actor 管理。为每个 WebSocket 创建一个新的 actor,并在 socket 关闭时被杀死。
该网页还显示了默认配置:
websockets-dispatcher = {
fork-join-executor {
parallelism-factor = 1.0
parallelism-max = 24
}
}
默认情况下,所有调度程序都将在线程池上运行他们的一组actor。因此,对于每个创建 websocket 的客户端,都会创建一个 actor。分配多少线程取决于使用哪个执行器服务。似乎fork-join-executor
将按需创建线程高达parallelism-max
.
除此之外,还有参与者来处理行动和承诺。
在 akka 中似乎有很多旋钮可以微调性能。请参阅http://doc.akka.io/docs/akka/2.0.1/general/configuration.html。使服务器“高度可扩展”可能涉及大量基准测试和一些硬件。
尽管 websocket 连接将有一个参与者池,但 ChatRoom 参与者仍然是唯一一个(单个参与者实例)对消息进行实际处理、管理连接/断开连接并充当套接字的路由器,这可能是此设计的瓶颈消息总是为演员按顺序处理的。我怀疑该示例是否旨在用于可扩展性,而是用于 websockets 的简单演示。