标签：
今天在看nginx thread pool的时候，频繁的看到sendfile，其实以前也经常看到sendfile，只是我平时选择性的忽视而已。。。 先说下sendfile，明天在好好聊下nginx 线程池的一些突发点， 通过伪官方的博客介绍了如何利用nginx 线程池aio，实现9倍的性能…. 个人看了下，他核心的概念就是把你认为堵塞的模块或者说是逻辑扔到线程池里面，然后去接受新的任务，当有结果的时候，在从线程池里面取结果，然后返回。。。 但是如果用在nginx最强大的静态文件处理上，我个人觉得提升不大，毕竟你就算承接了更多的客户端的请求，但是你最后返回数据的逻辑，还是在抢占式的堵塞… 毕竟磁盘io的能力是有限的…. 这只是个人的理解，如有不对的地方，请大家喷下…..
先不扯nginx线程池，回到sendfile…..
现在流行的web服务器里面都提供 sendfile 选项用来提高服务器性能
location /xiaorui.cc/ {
sendfile on;
tcp_nopush on;
aio on;
}
那么sendfile是什么东西，他是怎么影响性能的… … sendfile实际上是 Linux2.0+以后的推出的一个系统调用，web服务器可以通过调整自身的配置来决定是否利用 sendfile这个系统调用。先来看一下不用 sendfile的传统网络传输过程：
read(file,tmp_buf, len);
write(socket,tmp_buf, len);
硬盘 >> kernel buffer >> user buffer>> kernel socket buffer >>协议栈
一个基于socket的服务，首先读硬盘数据，然后写数据到socket 来完成网络传输的。上面2行用代码解释了这一点，不过上面2行简单的代码掩盖了底层的很多操作。来看看底层是怎么执行上面2行代码的：
1、系统调用 read()产生一个上下文切换：从 user mode 切换到 kernel mode，然后 DMA 执行拷贝，把文件数据从硬盘读到一个 kernel buffer 里。
2、数据从 kernel buffer拷贝到 user buffer，然后系统调用 read() 返回，这时又产生一个上下文切换：从kernel mode 切换到 user mode。
3、 系统调用write()产生一个上下文切换：从 user mode切换到 kernel mode，然后把步骤2读到 user buffer的数据拷贝到 kernel buffer（数据第2次拷贝到 kernel buffer），不过这次是个不同的 kernel buffer，这个 buffer和 socket相关联。
4、系统调用 write()返回，产生一个上下文切换：从 kernel mode 切换到 user mode ，然后 DMA 从 kernel buffer拷贝数据到协议栈。
上面4个步骤有4次上下文切换，有4次拷贝，我们发现如果能减少切换次数和拷贝次数将会有效提升性能。在kernel2.0+ 版本中，系统调用 sendfile() 就是用来简化上面步骤提升性能的。sendfile() 不但能减少切换次数而且还能减少拷贝次数。
再来看一下用 sendfile()来进行网络传输的过程：
sendfile(socket,file, len);
硬盘 >> kernel buffer (快速拷贝到kernelsocket buffer) >>协议栈
1、 系统调用sendfile()通过 DMA把硬盘数据拷贝到 kernel buffer，然后数据被 kernel直接拷贝到另外一个与 socket相关的 kernel buffer。这里没有 user mode和 kernel mode之间的切换，在 kernel中直接完成了从一个 buffer到另一个 buffer的拷贝。
2、DMA 把数据从 kernelbuffer 直接拷贝给协议栈，没有切换，也不需要数据从 user mode 拷贝到 kernel mode，因为数据就在 kernel 里。
简单说，sendfile是个比 read 和 write 更高性能的系统接口， 不过需要注意的是，sendfile 是将 in_fd 的内容发送到 out_fd 。而 in_fd 不能是 socket ， 也就是只能文件句柄。 所以当 Nginx 是一个静态文件服务器的时候，开启 SENDFILE 配置项能大大提高 Nginx 的性能。 但是当 Nginx 是作为一个反向代理来使用的时候，SENDFILE 则没什么用了，因为 Nginx 是反向代理的时候。 in_fd 就不是文件句柄而是 socket，此时就不符合 sendfile 函数的参数要求了。
标签：
原文地址：http://www.cnblogs.com/JohnABC/p/5864534.html
