优化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？我不确定我是否正确阅读了这些数字.

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

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

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

如果邮件在发布邮件时当前处于空闲状态,那么我们将使用邮箱计划Task.Factory.StartNew(mailboxAction).

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

有什么想法可能导致吞吐量完全打破16核心机器？在较小的机器上不会发生相同的效果,当它们无法再扩展时,它们在最大吞吐量时保持稳定.

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