Azure服务结构-分布式计算代码示例蒙特卡罗模拟-性能问题

本文关键字：模拟 蒙特卡罗 性能 问题 代码 服务 结构 分布式计算 Azure | 更新日期: 2023-09-27 18:24:31

听了最近的azure播客（尤其是关于在azure上构建低延迟金融系统的播客），并阅读了所有关于Service Fabric的宣传文章后，我决定尝试根据自己的需求更改"分布式计算代码示例蒙特卡罗模拟"模式。

我的设想是：一个请求是，在给定的起始状态下，使用一个简单的（计算上）基于蒙特卡罗的模型来运行10公里全程体育比赛模拟。

我的第一次尝试是：

  • 1*有状态的"处理器"参与者，接收匹配的开始状态并将其转发给10k以上的任务参与者，以及相关的聚合器参与者ID

    • 10K+*运行1个模拟并将结果传递给聚合器参与者的无状态"任务"参与者。模拟时间较小（~2ms）

    • 100*聚合的状态"聚合器"参与者接收模拟并传递给最终参与者

    • 1*计算最终结果的"最终参与者"

简单地使用Tasks在我的开发框上运行以上操作需要<100ms，但上面的设置（作为本地集群在开发机器上运行）花费了50秒甚至更多！

在调试完一个潜在的原因后，我发现Processor Actor发送初始任务所需的时间太长了，所以我想知道调用Service Fabric会产生什么样的开销（我想当我调用Actor的方法时，会发生各种命名服务调用），速度慢是否可能是由于这一点和我的任务数量？

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

  • 使所有参与者都成为无状态，以确保国家管理不会增加间接费用
  • 在Processor中创建了所有ActorProxy，并存储了它们的引用以备将来调用，以确保Actor Activations不会引起问题

有人对今后的发展有什么建议吗？或者有人试图实施类似的措施吗？

谢谢，Alex

Azure服务结构-分布式计算代码示例蒙特卡罗模拟-性能问题

我本来会把它作为评论发布的，但我还没有足够的声誉！如果您在Service Fabric的文档中引用了此页面，请查看文章下面的评论，特别是"tom"在2015年6月左右开始的评论跟踪。他在有状态的演员中表现不佳（每秒约20次手术），这似乎被认为是未来需要改进的领域。他们强调在非变异方法上使用只读属性可以显著提高性能。Abhishek Ram还包括一些注释和相关性能计数器信息的链接，这些信息可能有助于故障排除。

您注意到，您尝试使用对性能几乎没有影响的无状态参与者。我将进一步指出评论线索，其中另一个用户报告使用只读方法在单个参与者上每秒实现2k次以上的操作，我希望这种方法与无状态参与者方法类似。也许可以将来自性能计数器的信息与此进行比较，以查看您的性能与注释中的示例有多接近。

相关文章：