nginx中对静态文件进行了cache，对应的命令就是open_file_cache,open_file_cache_min_uses以及open_file_cache_valid。这次我就来分析下nginx如何对静态文件进行cache的。

要注意一个就是open_file_cache的 inactive表示文件多久不被访问就会从cache中删除.

首先来描述一下linux下是如何做的，因为这里nginx对于bsd版本有一个不同的做法，这是因为bsd中可以给kqueue监听文件改变的事件。而linux下，nginx并没有使用inotify，而是每次都会判断文件的st_ino来得到文件是否被修改，不过这样会有个缺点就是如果你是使用open，然后write来修改文件的话，文件其实是相同的，因此st_ino是相同的，此时nginx是无法知道的，因此修改的话，最好使用会先删除再覆盖的命令(比如cp)。

首先，nginx的cache只是cache句柄，因为静态文件的发送，一般来说，nginx都是尽量使用sendfile进行发送的，因此之需要cache句柄就够了。

所有的cache对象包含在两个数据结构里面，整个机制最关键的也是这两个东西，一个是红黑树，一个是一个队列，其中红黑树是为了方便查找(需要根据文件名迅速得到fd),而队列为了方便超时管理（按照读取顺序插入，在头的就是最近存取的文件)，由于所有的句柄的超时时间都是一样的，因此每次只需要判断最后几个元素就够了，因为这个超时不需要那么实时.

假设现在客户端请求是GET test.html HTTP/1.1 ,则nginx是这么处理的，如果test.html在cache中存在，则从cache中取得这个句柄，然后正常返回，如果test.html不存在，则是打开这个文件，然后插入到cache中。不过这里有很多细节都需要处理，比如超时，比如红黑树的插入等等，接下来，我们就对照着代码来看这些都是如何处理的。

前面我介绍过google对内核协议栈的patch，RPS,它主要是为了软中断的负载均衡，这次继续来介绍google 的对RPS的增强path RFS(receive flow steering),RPS是把软中断map到对应cpu，而这个时候还会有另外的性能影响，那就是如果应用程序所在的cpu和软中断处理的cpu不是同一个，此时对于cpu cache的影响会很大。 这里要注意，在kernel 的2.6.35中 这两个patch已经加入了。

ok,先来描述下它是怎么做的，其实这个补丁很简单，想对于rps来说就是添加了一个cpu的选择，也就是说我们需要根据应用程序的cpu来选择软中断需要被处理的cpu。这里做法是当调用recvmsg的时候，应用程序的cpu会被存储在一个hash table中，而索引是根据socket的rxhash进行计算的。而这个rxhash就是RPS中计算得出的那个skb的hash值.

可是这里会有一个问题，那就是当多个线程或者进程读取相同的socket的时候，此时就会导致cpu id不停的变化，从而导致大量的OOO的数据包(这是因为cpu id变化，导致下面软中断不停的切换到不同的cpu，此时就会导致大量的乱序的包).

基本的x86体系下系统调用相关的指令可以看这篇文章。

x86下，最早是使用软中断指令int 0×80来做的，不过现在内核是使用syscall和sysenter指令，只有64位下才会使用syscall,而大部分情况都是使用sysenter,这里我们主要介绍sysenter指令，不过具体实现3者现在都差不多，这是因为内核使用了VDSO来兼容所有的指令，接下来我们就要来详细的分析内核是如何实现vdso层，以及glibc库(也就是用户空间)是如何来调用vdso层的接口，从而进入内核。

我这里内核版本是2.6.35,cpu架构是x86_32.先来看linux下进程的结构。

首先我们要知道在linux中第一个进程是内核进程，pid为0，它是所有的进程的父进程。这个进程也叫swapper，或者说是idle.

前几天nginx的0.8.x正式成为stable，然后看了下代码，发现0.8加入了linux native aio的支持，我们知道在linux下有两种aio，一种是glibc实现的aio，这个比较烂，它是直接在用户空间用pthread进行模拟的。还有一种就是内核实现的aio，这些系统调用是以io_xxx开始的，而在nginx的0.8 中使用的是后一种,下面我们简称后一种为native aio.这里注意native aio只支持direct io。

然后是charset filter，这个主要是处理nginx内部的charset命令，转换为设置的编码。这个filter就不介绍了，主要是一个解码的过程。

再接下来是chunk filter,它主要是生成chunk数据，这里要注意nginx只支持服务端生成chunk，而不支持客户端发送的chunk数据。chunk的格式很简单，简单的来说就是大小+数据内容。

先来看chunk的header filter，在filter中，主要是用来判断是否需要chunk数据，然后设置相关标记位，以便于后面的body filter处理.

这里主要的头的处理是放在filter中做的，我们首先来看config(默认情况)后，nginx的obj目录下的ngx_modules.c这个文件中的关于filter的部分：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

     
ngx_module_t *ngx_modules[] = {
  
…………………………………………
      
&ngx_http_write_filter_module,
      
&ngx_http_header_filter_module,
      
&ngx_http_chunked_filter_module,
      
&ngx_http_range_header_filter_module,
      
&ngx_http_gzip_filter_module,
      
&ngx_http_postpone_filter_module,
      
&ngx_http_ssi_filter_module,
      
&ngx_http_charset_filter_module,
      
&ngx_http_userid_filter_module,
      
&ngx_http_headers_filter_module,
      
&ngx_http_copy_filter_module,
      
&ngx_http_range_body_filter_module,
      
&ngx_http_not_modified_filter_module,
      
NULL
  
};

man 7 epoll会发现这个东西,就是使用epoll中会遇到的问题：

o If using an event cache… If you use an event cache or store all the file descriptors returned from epoll_wait(2), then make sure to provide a way to mark its closure dynamically (i.e., caused by a previous event’s processing). Suppose you receive 100 events from epoll_wait(2), and in event #47 a condition causes event #13 to be closed. If you remove the structure and close(2) the file descriptor for event #13, then your event cache might still say there are events waiting for that file descriptor causing confusion.

这种事件也可以叫做stale event，而下面是man手册提出的解决方法：

One solution for this is to call, during the processing of event 47, epoll_ctl(EPOLL_CTL_DEL) to delete file descriptor 13 and close(2), then mark its associated data structure as removed and link it to a cleanup list. If you find another event for file descriptor 13 in your batch process‐ ing, you will discover the file descriptor had been previously removed and there will be no confusion.

问题很简单，由于大部分的服务器都会有一个连接池。而连接池是通过fd来进行定位，前面处理的事件会影响后面的事件，比如关闭掉了后面的事件，而后关闭掉的事件在当前的循环中还是会被处理，这种情况很好处理，比如设置fd为－1，就可以检测，可是还有一种情况，就是当你关闭了fd，然后设置－1之后，恰好接收到的新的连接的fd刚好和刚才close的fd的值是一样的。此时就会引起混乱了，也就是说我们需要区分事件是不是stale event，或者说是我们方才释放掉的fd被重新使用，而nginx中并没有按照上面man手册里面的方法，它的做法很巧妙，我们来看nginx如何做的。 首先要知道在nginx中是存在一个连接池的，所有的连接的获取和释放都是通过连接池来进行的，nginx中连接池很简单，就是一个简单的数组，有一个free_connections变量保存了所有可以使用的连接，它是一个链表，它的构造是这样子的，每个连接都有一个域data，如果释放一个连接，则这个连接的data就指向当前的free_connects,然后当前的释放的连接直接指向free_connections,也就是一个将连接加入free链表的 动作。

这里我的gcc是4.5.1 binutils 是2.20.1 ，内核是2.6.35.3.

首先需要交叉编译gcc和binutils

port安装 gcc编译依赖的库gpm，mpfr和mpc.

然后开始编译gcc，这里有个要注意的就是需要指定gmp的include和lib路径，下面是我的config：

这个是以前blog上写的一些，不过只是分析了一部分，以后会把代码分析完的，这里我把前面分析的做成了pdf供大家 下载