Question

编辑：这是Does Akka Tcp support full-duplex communication? 的副本（请不要多次提出同样的问题，在邮件列表上复制也是如此，这会浪费那些人的时间自愿提供帮助，减少将来获得答案的机会。

我已经从https://github.com/akka/akka/blob/master/akka-docs/rst/scala/code/docs/io/EchoServer.scala#L96

修改了Echo服务器

case Received(data) =>
  connection ! Write(data, Ack(currentOffset))
  log.debug("same {}", sender.eq(connection)) // true
  buffer(data)

这意味着传入和传出的消息由同一个actor处理。因此，单个工作线程（从邮箱接收消息）将处理读写操作。看起来像是一个潜在的瓶颈。

在“经典”世界中，我可以创建一个线程来从套接字读取，另一个线程用于写入并获得同步通信。

更新谷歌小组https://groups.google.com/forum/#!topic/akka-dev/mcs5eLKiAVQ

中的讨论

Answer 1

虽然在任何给定的时间点都有一个Actor可以读取或写入，但是这些操作中的每一个都只需要很少的周期，因为它只在有待读取的数据或可写入的缓冲区空间时才会发生。大约1μs的系统调用开销意味着默认缓冲区大小为128kiB，你应该总共可以传输高达100GiB / s，这肯定是一个瓶颈，但可能不是今天和实际上（这大致与典型的CPU内存一致）带宽，所以无论如何更多的数据速率是不可能的）。一旦发生这种变化，我们就可以分开不同选择器之间的读写责任并唤醒不同的Actors，但在此之前我们需要验证实际上是否存在可测量的影响。

需要回答的另一个问题是哪个操作系统内核实际上允许来自多个线程的单个套接字上的并发操作。我还没有对此进行过研究，但我不会惊讶地发现完全独立的锁定很难做到，并且可能还没有（还）有理由花费这些精力。

Akka.IO Tcp是否存在双向通信的瓶颈？

1 个答案: