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

Question

我正在使用一个Service Fabric应用程序,我无法像希望的那样执行它.

主要问题与一个演员调用另一个演员有关.我正在记录从调用actor看到的给定调用所需的时间,并记录在接收actor上花费的时间.

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

这是可以预期的吗？创建一个全新的演员实例肯定是最糟糕的 - 但是即使我在调用演员时我也会看到这种事情,我之前做过不同的调用.

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

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

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

我将补充说,这是在一个安静的测试环境中,因此被其他请求锁定的演员不是问题.

我可以根据要求提供更多信息,但我不太确定最相关的内容.

Answer 1

在您的场景中需要考虑许多变量，并且瓶颈可能无处不在。您可能知道，致电演员并获得回复需要执行许多步骤。我将提供一些常见的，您进一步研究。

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

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

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