Azure Service Fabric - 分布式计算代码示例 Monte Carlo 模拟 - 性能问题

Question

听了最近的 azure 播客（特别是关于在 azure 上构建低延迟金融系统的播客）并阅读了有关 Service Fabric 的所有炒作后，我决定尝试根据我的需要更改“分布式计算代码示例蒙特卡罗模拟”模式。

我的场景是：一个具有给定起始状态的请求，使用简单的（计算上的）基于蒙特卡罗的模型运行 10k 场完整的体育比赛模拟。

我的第一次尝试是：

• 1 * 有状态的“处理器”Actor，它接收比赛的开始状态并将其转发给 10k + 任务 Actor，以及相关的聚合器 ActorId

  • 10K+ * 运行 1 次模拟并将结果传递给其聚合器 Actor 的无状态“任务”Actor。 模拟时间很短（~2ms）

  • 100 * 有状态的“聚合器”Actor 聚合收到的模拟并传递给终结器 Actor

  • 1 * 'Finaliser' 计算最终结果的 Actor

仅使用 Tasks 在我的开发机器上运行上述内容需要 < 100 毫秒，但上述设置（在开发机器上作为本地集群运行）需要 50 秒甚至更多！

在调试通过一个潜在的原因后，我发现处理器 Actor 发送初始任务所需的时间，所以我想知道调用 Service Fabric 有什么样的开销（我猜各种命名服务调用都在发生当我调用演员的方法时）以及缓慢是否可能是由于这个和我的任务数量？

为了消除其他可能性，我执行了以下操作，并注意到总时间只有很小的差异：

• 使所有参与者无状态，以确保状态管理不会增加开销。
• 在处理器中创建所有 ActorProxies 并存储它们的引用以供将来调用以确保 Actor 激活不会导致问题。

有没有人对从这里去哪里有任何建议，或者有没有人尝试实施类似的东西？

谢谢，亚历克斯

Answer 1

我会将此作为评论发布，但我还没有足够的声誉！ 如果您在 Service Fabric 的文档中引用了此页面，请查看文章下方的评论，尤其是“tom”在 2015 年 6 月左右的某个时间开始的评论线索。他在使用有状态参与者时性能不佳（每秒约 20 次操作） ，这似乎被认为是未来改进的领域。 他们强调在非变异方法上使用只读属性可以显着提高性能。 Abhishek Ram 还包含一些注释和指向相关性能计数器信息的链接，这些信息可能有助于故障排除。

您注意到您尝试使用对性能影响很小的无状态actor。 我会进一步指出评论跟踪，其中另一个用户报告使用只读方法在单个 actor 上实现了每秒 2k+ 次操作，我希望其执行类似于无状态 actor 方法。 也许可以将来自性能计数器的信息与此进行比较，以查看您的性能与评论中有些微不足道的示例的匹配程度。