performance - 在 Akka 中创建 Actor 的成本是多少？

Question

考虑一个场景，我正在实现一个使用 Akka 处理传入任务的系统。我有一个主要参与者，它接收任务并将它们分派(dispatch)给一些处理任务的工作参与者。

我的第一直觉是通过让调度程序为每个传入任务创建一个 Actor 来实现这一点。工作角色处理完任务后，它会停止。

这对我来说似乎是最干净的解决方案，因为它遵循“一个任务，一个 Actor ”的原则。另一种解决方案是重用 Actor - 但这涉及清理和一些池管理的额外复杂性。

我知道 Akka 的 Actor 很便宜。但我想知道是否存在与重复创建和删除 Actor 相关的固有成本。 Akka 用于记录参与者的数据结构是否存在任何隐藏成本？

负载应该是每秒数十或数百个任务的数量级 - 将其视为一个生产网络服务器，每个请求创建一个参与者。

当然，正确的答案在于根据输入负载的类型对系统进行分析和微调。
但我想知道是否有人可以根据自己的经验告诉我一些事情？

后期编辑:

我应该提供有关手头任务的更多详细信息:

只有 N 个事件任务可以在某个时间点运行。正如@drexin 指出的那样 - 这可以使用路由器轻松解决。但是，任务的执行不是简单的运行和完成类型的事情。

任务可能需要来自其他参与者或服务的信息，因此可能必须等待并进入休眠状态。通过这样做，他们释放了一个执行槽。这个槽可以被另一个等待的actor占据，它现在有机会运行。您可以类比进程在一个 CPU 上的调度方式。

每个 worker 参与者都需要保持一些关于任务执行的状态。

注:我很欣赏我的问题的替代解决方案，我一定会考虑它们。但是，我还想回答有关在 Akka 中密集创建和删除 Actor 的主要问题。

Answer 1

您不应该为每个请求创建一个参与者，而应该使用路由器将消息分发给动态数量的参与者。这就是路由器的用途。阅读这部分文档以获取更多信息:http://doc.akka.io/docs/akka/2.0.4/scala/routing.html

编辑:

创建顶级actor (system.actorOf) 的成本很高，因为每个顶级actor 也会初始化一个错误内核，而且成本很高。创建子 Actor (在 Actor 内 context.actorOf )要便宜得多。

但我仍然建议你重新考虑这一点，因为根据创建和删除 Actor 的频率，你也会对 GC 施加额外的压力。

编辑2:

最重要的是， Actor 不是线程!因此，即使您创建了 1M 个actor，它们也只能在池中的线​​程数上运行。因此，根据配置中的吞吐量设置，每个参与者将在线程再次释放到池之前处理 n 条消息。

请注意，阻塞线程(包括 sleep )不会将其返回到池中!