应用错误收集

我正在使用Service Fabric应用程序，我无法像希望的那样执行该应用程序。

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

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

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

传递的参数非常基础 - 我不怀疑反序列化是个问题。

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

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

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

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

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

要知道的第一步是您的actor所在的位置，因此调用者必须调用将在命名服务中找到actor地址的Proxy。第一次通话需要一段时间才能发现他们的地址。以下对同一个Actor的调用将被缓存。
需要建立呼叫者和演员之间的连接，如果他们在不同的节点中，则会为您的呼叫增加额外的延迟。
您的邮件和响应的序列化也需要几毫秒，并且根据邮件的大小，这可能需要相当长的时间。
在处理请求之前，actor激活过程可能需要做一些工作，比如loading \ saving \ sync the actor state。
Actor线程同步：如果你同时点击同一个actor，那么这些调用将按顺序排队和处理，所以如果你同时对同一个actor进行5次调用，并且每次调用需要大约1秒钟，在等待状态下，您的一个电话将需要大约5秒钟才能完成。

因此，如果您考虑这些基本要点，您的服务可能会触及网络＆amp;发现延迟，序列化和并发调度，演员创建＆amp;数据同步。

根据您的情况，我认为问题是并发性而不是其他任何问题。在下列请求之前，您可能会在\之后锁定演员