Azure服务结构 - 分布式计算代码示例Monte Carlo仿真 - 性能问题

Question

听过最近的azure播客（特别是关于在azure上构建低延迟金融系统的播客）并阅读所有关于服务结构的宣传，我决定尝试修改“分布式计算代码示例蒙特卡洛模拟”模式适合我的需求。

我的场景是： 使用一个简单的（计算明智的）基于monte-carlo的模型，用一个给定的起始状态运行10k个全运动比赛模拟的一个请求。

我第一次尝试是：

• 1 *接收匹配的启动状态，并将其转发到10k +任务演员，相关聚合的actorId

  沿着有状态的“处理器”演员

  • 10K + * StateLess'Task'Actor运行1次模拟并将结果传递给其聚合器Actor。仿真时间小（〜2毫秒）

  • 100 *有状态“聚合器”行动者聚集接收到的模拟和传递到finaliser演员所计算的最终结果

• 1 *“Finaliser”演员

运行在仅使用任务我开发框上面的花费< 100毫秒，但上面的设置（在开发计算机上运行的本地集群）把50secs和更多！

调试通过一个潜在的原因，我发现是处理器角色发送初始任务所需的时间量，所以我想知道什么样的开销在调用服务结构（我想各种命名当我打电话给演员的方法时，服务电话正在发生）以及这种缓慢是否可能是由于这一点以及我的任务数量？

要消除其他可能我做了以下，发现只有在总时间非常小的差异：

• 的所有演员无国籍，保证国家管理不增加开销。
• 在处理器中创建所有ActorProxy，并存储它们的引用以备将来调用，以确保Actor Activations不会引起问题。

有没有人有什么建议可以从这里走，还是有人试图实施类似的东西？

谢谢， 亚历克斯

Answer 1

我会公布这是一个评论，但我还没有足够的信誉为保证！如果您在Service Fabric的文档中参考this page，请查看文章下方的注释，特别是2015年6月前后“tom”开始的评论跟踪。他的性能差（每秒约20次操作），有状态演员，这似乎被认为是未来改进的一个领域。他们强调对非变异方法使用只读属性来显着提高性能。Abhishek Ram还包括一些说明和information on relevant performance counters的链接，可能有助于排除故障。

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