c# - Azure Service Fabric - 分布式计算代码示例蒙特卡洛模拟 - 性能问题

Question

在听了最近的 azure 播客(特别是关于在 azure 上构建低延迟金融系统的播客)并阅读了有关 Service Fabric 的所有宣传后，我决定尝试更改“分布式计算代码示例蒙特卡罗模拟”模式以满足我的需求.

我的场景是:一个请求，在给定的起始状态下使用基于简单(计算方面)蒙特卡洛的模型来运行 10k 次完整的体育比赛模拟。

我的第一次尝试是:

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

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

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

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

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

在调试了一个潜在原因后，我发现处理器 Actor 发送初始任务所花费的时间，所以我想知道调用 Service Fabric 会产生什么样的开销(我猜是各种命名服务)当我调用 Actor 的方法时发生调用)以及缓慢是否可能是由于这个和我的任务数量造成的？

为了消除其他可能性，我执行了以下操作，发现总时间只有很小的差异:

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

有人对下一步的发展有什么建议，或者有人尝试过实现类似的东西吗？

谢谢，亚历克斯

Answer 1

我本来可以将此作为评论发布，但我还没有足够的声誉!如果您引用this page在 Service Fabric 的文档中，请查看文章下面的评论，特别是由“tom”在 2015 年 6 月左右发起的评论轨迹。他在使用有状态 Actor ，这似乎被认为是 future 需要改进的一个领域。他们强调在非变异方法上使用只读属性可以显着提高性能。 Abhishek Ram 还提供了一些注释和 information on relevant performance counters 的链接。这可能有助于排除故障。

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