为什么EventMachine比Node慢得多？

Question

在我的具体案例中，至少。不要在这里做一般性陈述。

我已经在Node.js中编写了这个Web爬虫。我喜欢使用Ruby，所以我在EventMachine中重写了它。由于原版是在CoffeeScript中，它实际上非常容易，并且代码非常相似，除了在EventMachine中我实际上可以捕获并从异常中恢复（因为我使用的是光纤）。

问题是在Node.js代码上运行不到20秒的测试在EventMachine上花费超过5分钟。当我观察连接计数时，它几乎看起来甚至没有并行运行（它们排队成数百个，然后非常缓慢地向下运行），尽管日志记录显示代码点 命中并行。

我意识到没有代码就无法确切地知道到底发生了什么，但我只是想知道是否存在某种潜在的差异，我应该放弃，或者他们是否应该能够以快速（小幅减速很好）我应该继续试图找出问题所在。

我做了以下操作，但它似乎没有任何影响：

puts "Running with ulimit: " + EM.set_descriptor_table_size(60000).to_s
EM.set_effective_user('nobody')
EM.kqueue

哦，我非常确保我在EventMachine中没有任何阻止调用。我已经梳理了大约10次每一行，寻找任何可能阻塞的东西。我的所有网络调用都是EM :: HttpRequest。

Answer 1

  

问题是在Node.js代码上运行不到20秒的测试在EventMachine上花费超过5分钟。当我看到连接计数时，它几乎看起来甚至没有并行运行（它们排队成数百个，然后非常缓慢地向下运行），尽管日志记录显示代码点是并行命中的。

如果它们没有并行运行，那么它不是异步的。所以你要阻止。

基本上，您需要弄清楚在标准Ruby库中阻止IO调用的内容并删除它并将其替换为EventMachine非阻塞IO调用。

您的代码可能没有任何阻止调用，但您使用的是不是您自己的第三方代码EM？他们可能会阻止。即使像调试打印/日志这样简单的东西也可以阻止。

  

我所有的网络电话都是EM :: HttpRequest。

文件IO怎么样，TCP怎么样？什么其他可以阻止的东西呢。那第三方图书馆呢。

我们真的需要在这里看到一些代码。要么在代码中识别瓶颈，要么阻止调用。

node.js不应该比EM快一个数量级。