优化Akka.NET消息调度程序

Question

我目前正试图在Akka.NET的消息调度程序中找到瓶颈（java / scala actor模型框架的端口） 对于那些感兴趣的人，可以在这里找到：https://github.com/akkadotnet/akka.net

我们似乎可以扩展至8核心，到目前为止一切似乎都很好。 但是，当在较大的机器上运行时，一切都会最终崩溃。 我们已经在16核计算机上测试了它，它可以很好地扩展到某一点，然后突然，消息吞吐量减半。

此图片正在我的笔记本电脑上进行分析 有关完整图片，请参阅：http://i.stack.imgur.com/DxboR.png

。 瓶颈是Task.Factory.StartNew，还是ConcurrentQueue.Enqueue？ 我不确定我是否正确阅读了这些数字。

以下是我们的邮件调度程序和邮箱如何工作的简要说明：

邮件发布到邮箱后，邮箱会检查邮箱当前是否正在处理邮件。 如果它正在处理消息，它只是让当前正在运行的任务消耗新消息。

基本上，我们将一条消息发布到ConcurrentQueue，当前的邮箱运行将找到它。

如果在发布邮件时邮箱当前处于空闲状态，那么我们会使用Task.Factory.StartNew(mailboxAction)来安排邮箱。

为了确保在任何给定时间只有一个任务针对特定邮箱运行，我们使用Interlocked检查来查看邮箱是忙还是空闲。 联锁检查有效，经过广泛测试，因此我们知道我们不会为同一个邮箱启动多个任务。

任何可能导致吞吐量完全破坏16核心机器的想法？ 在较小的机器上不会发生同样的效果，当它们无法再扩展时，它们在最大吞吐量时保持稳定。

我在16核心机器上验证的一件事是，邮箱似乎处理得太快，耗尽了actor消息队列中的所有消息，一旦新消息到达，这将导致邮箱的新调度。 也就是说，消费者比生产者更快。