azure-service-fabric - Service Fabric Actor 的性能是否不可靠？

Question

我正在使用 Service Fabric 应用程序，但我不太能够像希望的那样执行该应用程序。

主要问题与一个 Actor 调用另一个 Actor 有关。我正在记录从调用actor看到的给定调用花费的时间，并记录在接收actor上花费的时间。

我看到的是，接收参与者记录工作负载需要几毫秒(最多 20 毫秒)。但是，调用actor 会记录从 50 毫秒到超过 2 秒的任何内容。我无法解释的延迟发生在实际逻辑运行之前。一旦方法返回，调用actor 就会快速获得响应。

这是可以预期的吗？创建全新的 Actor 实例时绝对是最糟糕的 - 但我看到这种事情，即使我调用 Actor 时，我也早些时候做了不同的电话。

传递的参数相当基本 - 我不怀疑反序列化是问题所在。

我意识到 actor 将分布在集群内，但这种规模的开销似乎不成比例。

所以，我的问题是:这是“按预期”还是表明我们做错了什么？

我要补充的是，这是在一个安静的测试环境中，因此 Actor 被其他请求锁定不是问题。

我可以根据要求提供更多信息，但我不太确定哪些信息最相关。

Answer 1

在您的场景中有许多变量需要考虑，瓶颈可能无处不在。
正如您可能知道的那样，调用参与者并获得响应需要许多步骤。
我将提供一些常见的，你进一步调查。

要知道的第一步是您的actor 所在的位置，因此调用者必须调用将在命名服务中找到actor 地址的代理。第一次调用需要一段时间才能发现他们的地址。对同一个 Actor 的以下调用将被缓存。

需要建立调用者和参与者之间的连接，如果它们位于不同的节点中，则您的调用会增加额外的延迟。

消息和响应的序列化也需要几毫秒，并且根据消息的大小，这可能需要相当长的时间。

在处理请求之前，actor 激活过程可能需要做一些工作，比如加载\保存\同步actor 状态。

Actor线程同步:如果你同时命中同一个actor，调用会依次入队和处理，所以如果你同时对同一个actor进行5次调用，每个调用大约需要1秒处理，你的一个调用在等待状态下，调用大约需要 5 秒钟才能完成。

因此，如果您考虑这些基本点，您的服务可能会遇到网络和发现延迟、序列化和并发调度、actor 创建和数据同步。

根据您的情况，我认为问题是并发性比其他任何事情都重要。可能您在以下请求之后\之前锁定了 Actor