非阻塞io与阻塞io对原始数据吞吐量的影响

Question

在apache HTTPComponent文档中有一条语句：

与流行的观点相反，NIO在原始数据吞吐量方面的性能明显低于阻塞I/O。“

这是真的吗？有人能更详细地解释一下吗？什么是典型的用例

请求/响应处理需要解耦

Answer 1

当您可以处理请求、在其他执行上下文(不同线程、对另一台服务器的RPC调用、其他异步机制)上处理它并释放web服务器的线程以处理更多传入请求时，应该使用非阻塞IO。当响应处理完成时，将调用响应处理线程，并将响应发送到客户端。

为了更好地理解这个概念，我建议阅读netty文档。

至于更高的吞吐量:当服务器发送/接收大量数据时，所有这些上下文切换以及线程之间的数据传递都会严重影响整体性能。可以这样想:您收到了一个大请求(将请求放入一个大文件中)。您所需要做的就是将其保存到磁盘中，并返回OK。开始在线程之间抛出它可能会导致更多的mem复制操作，如果您只是将其抛到同一线程中的磁盘中，则可能需要更多的mem拷贝操作。以异步方式处理此操作不会提高性能:虽然您可以将请求处理线程释放回web服务器的线程池，并让它处理其他请求，但您的主要性能瓶颈是磁盘IO，在这种情况下--尝试同时保存更多的文件--只会使事情变慢。

希望我说的够清楚了。如果您需要更多的解释，请随时在评论中提出更多的问题。

Answer 2

第一条语句只有在并发请求的数量相对较少(而不是成千上万)时才是正确的。这是关于使用多个线程(阻塞)而不是一个或几个线程(非阻塞)。假设您想编写一个只从远程服务器下载文件的应用程序。如果您的应用程序一次只需要下载一个文件，则只需要一个线程。但是，如果您有一个运行数千个HTTP请求的爬虫，那么您需要有数千个线程(或者使用有限数量的线程+ NIO )。对于如此多的线程来说，问题在于上下文切换，这会极大地降低应用程序的速度(因此，对于这个数量的并发请求，NIO更好)。

但让我们回到你的问题。为什么NIO在原始数据吞吐量方面会变慢呢？原因是NIO驱动的应用程序所使用的CPU时间。对于这种情况，在阻塞模型中，代码只做一件事--等待数据(它在循环中执行recv()操作)。在NIO应用程序中，逻辑要复杂得多:在循环中，代码使用选择器选择一组键(这涉及到Linux上的epoll_wait系统调用，Oracle )，然后遍历集合，为每个键获取一个通道，然后从通道读取数据(OS中的read ()操作)。在标准阻塞模型中，您所要做的就是执行recv()系统函数。总之:在这种情况下，NIO驱动的应用程序使用更多的CPU时间，并且由于更多的系统调用而产生更多的模式切换操作(所谓模式切换，我指的是从用户模式到内核模式的切换)。因此，下载该文件所需的时间将更长。