Service Fabric Actor 的性能是否不可靠？答案

【问题标题】：Is Service Fabric Actor performance unreliable?Service Fabric Actor 的性能是否不可靠？
【发布时间】：2018-07-04 04:46:48
【问题描述】：

我正在使用一个 Service Fabric 应用程序，但我无法达到预期的效果。

主要问题与一个演员调用另一个演员有关。我正在记录从调用参与者看到的给定呼叫需要多长时间，并且我记录在接收参与者上花费的时间。

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

这是可以预料的吗？创建一个全新的演员实例时绝对是最糟糕的 - 但即使我在调用演员时我也看到了这种事情，我之前做了一个不同的调用。

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

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

所以，我的问题是：这是“如预期的那样”还是表明我们做错了什么？

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

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

【问题讨论】：

【解决方案1】：

在您的方案中需要考虑许多变量，瓶颈可能无处不在。正如您可能知道调用演员并获得响应，您需要许多步骤。我将提供一些常见的，您可以进一步调查。

第一步要知道你的actor所在的位置，所以调用者必须调用将在命名服务中找到actor地址的代理。第一次调用需要一段时间才能发现他们的地址。以下对同一 Actor 的调用将被缓存。
需要建立调用者和参与者之间的连接，如果它们位于不同的节点中，则会为调用增加额外的延迟。
消息和响应的序列化也需要几毫秒，根据消息的大小，这可能需要相当长的时间。
actor 激活过程在处理请求之前可能需要做一些工作，例如加载\保存\同步 actor 状态。
Actor线程同步：如果同时命中同一个actor，调用会按顺序排队处理，所以如果你同时对同一个actor进行5次调用，每次调用处理大约需要1秒，在等待状态下，您的一个呼叫大约需要 5 秒才能完成。

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

根据您的情况，我认为问题在于并发性。在以下请求之后\之前，您可能有一些东西锁定了演员

【讨论】：

感谢您的回复。这也是我最初的想法——那是一个并发问题。但是，我在受控环境中看到这种行为，其中只有一个参与者调用另一个参与者而不是并行。我几乎已经将其排除在（唯一的）问题之外。我也知道你提到的步骤——但“毫秒”是关键词。有时会有几百毫秒的开销，我不会感到惊讶 - 但经常看到 1-2 秒似乎很不合适。被序列化的有效负载大多很小，我看不出消息大小和延迟之间有任何关联。
如果你提供一个样本会很有帮助，没有太多细节我们只能假设。