在阅读了关于事件循环以及node.js中异步如何工作之后，这是我对node.js的理解：
但这是我的问题： 只有当处理节点发送的请求的实体（服务器/进程/线程？）而不是节点服务器本身时，非阻塞I / O似乎比阻塞I / O更快。 / p>
处理请求的服务器与发出请求的服务器相同时会出现什么情况？如果我的第一个项目符号是正确的，在这种情况下，如果阻塞I / O使用不同的线程来执行任务，那么阻塞I / O的工作速度会比非阻塞更快 文件压缩是否是这种I / O任务的一个例子，它在多线程阻塞I / O上运行得更快？
答案 0 :(得分：2)
非阻塞操作的主要好处是，当服务器等待其他地方发生某些事情时，相对较重的CPU线程不会保持忙碌（网络，磁盘I / O等......）。这意味着许多不同的请求可以在飞行中＆＃34;只有单个CPU线程，没有线程卡在等待I / O.开发人员需要负担编写异步友好代码并使用异步I / O操作的负担，但在繁重的I / O绑定操作中，服务器可伸缩性可能会带来真正的好处。单线程模型也真正简化了对共享资源的访问，因为线程冲突，死锁等的机会远远少于此......这可以减少难以发现的线程同步错误，这些错误往往只会破坏您的服务器最糟糕的时间（例如，当它忙碌时）。
是的，非阻塞I / O只有在处理I / O操作的代理不是node.js本身时才有帮助，因为节点中非阻塞I / O的整个点是该节点可以自由使用它单线程在I / O操作运行时执行其他操作，如果它的节点正在为I / O操作提供服务，则该操作不会成立。
很抱歉，但我不了解您关于文件压缩的部分问题。文件压缩需要一定数量的CPU，无论谁处理它，如果你试图决定是在节点本身内部还是在外部进程（运行不同的线程）中处理它，那么会有很多不同的考虑因素。这不是一个简单的问题。我可能会开始使用我已经用于压缩的任何代码（例如，使用节点代码，如果你拥有的是什么，或者使用外部库/进程，如果这是你拥有的），并且只调查如果您实际遇到性能或可伸缩性问题或者知道您遇到问题，则可以使用其他选项。
仅供参考，一个处理压缩的简单机制是将未压缩的数据从你的node.js应用程序转移到临时目录中的文件，然后让另一个进程（可以写入任何系统，甚至包括节点）查找应用压缩的临时目录中的文件，然后使用生成的压缩数据执行更永久的操作。