pagefault

这篇主要分析下mochiweb的整体结构。

我这里看的代码是github上的最新代码( https://github.com/mochi/mochiweb )。

由于mochiweb是一个框架，因此我们就从他自带的简单例子入手，来看他是如何工作的。我们就从keepalive.erl开始。

首先来看这个模块的start函数，也就是它的启动函数：

-define(LOOP, {?MODULE, loop}).

start(Options = [{port, _Port}]) ->
    mochiweb_http:start([{name, ?MODULE}, {loop, ?LOOP} | Options]).

可以看到启动函数非常简单，那就是直接调用mochiweb_http模块的start函数。那么我们整个分析流程，就从这个模块的start函数开始。这里要注意，我们可以看到是将当前回调模块的loop函数传递给了mochiweb_http,这就给后续调用回调，提供了接口。

%% @spec start(Options) -> ServerRet
%%     Options = [option()]
%%     Option = {name, atom()} | {ip, string() | tuple()} | {backlog, integer()}
%%              | {nodelay, boolean()} | {acceptor_pool_size, integer()}
%%              | {ssl, boolean()} | {profile_fun, undefined | (Props) -> ok}
%%              | {link, false}
%% @doc Start a mochiweb server.
%%      profile_fun is used to profile accept timing.
%%      After each accept, if defined, profile_fun is called with a proplist of a subset of the mochiweb_socket_server state and timing information.
%%      The proplist is as follows: [{name, Name}, {port, Port}, {active_sockets, ActiveSockets}, {timing, Timing}].
%% @end
start(Options) ->
    mochiweb_socket_server:start(parse_options(Options)).

阅读全文…

Nginx的配置解析相关的部分比较绕，比如为何要有4重指针，比如NGX_MAIN_CONF ， loc_conf,NGX_DIRECT_CONF有什么区别呢?这些我前面的blog都有些涉及，这次主要是把配置这块完全拿出来然后来分析下。

首先来看配置解析时的数据结构，这里主要是ngx_conf_t，这个结构保存了解析配置文件所需要的一些域，这个是非常重要的一个数据结构，我们详细来看这个结构：

struct ngx_conf_s {
//当前解析到的命令名
    char                 *name;
//当前命令的所有参数
    ngx_array_t          *args;

//使用的cycle
    ngx_cycle_t          *cycle;
//所使用的内存池
    ngx_pool_t           *pool;
//这个pool将会在配置解析完毕后释放。
    ngx_pool_t           *temp_pool;
//这个表示将要解析的配置文件
    ngx_conf_file_t      *conf_file;
//配置log
    ngx_log_t            *log;

//主要为了提供模块的层次化(后续会详细介绍)
    void                 *ctx;
//模块类型
    ngx_uint_t            module_type;
//命令类型
    ngx_uint_t            cmd_type;

//模块自定义的handler
    ngx_conf_handler_pt   handler;
//自定义handler的conf
    char                 *handler_conf;
};

阅读全文…

Nginx的cache实现比较简单，没有使用内存，全部都是使用文件来对后端的response进行cache，因此nginx相比varnish以及squid之类的专门做cache的server，可能效果不会那么好。特别如果cache内容比较大的话。不过还有一种折衷的处理，那就是挂载一个内存盘，然后让nginx cache到这个盘。

我这里的看的代码是1.1.17.

首先来看Nginx中如何开启cache，http cache主要是应用在upstream中的，因此upstream对应的两个命令来启用cache，一个是xxx_cache_path(比如proxy_cache_path)，它主要是用来创建管理cache的共享内存数据结构(红黑树和队列).一个是xxx_cache,它主要是使用前面创建的zone。

先来看第一个命令，xxx_cache_path,它会调用ngx_http_file_cache_set_slot函数，在看这个函数之前，先来看ngx_http_file_cache_t这个数据结构，它主要用来管理所有的cache文件，它本身不保存cache，只是保存管理cache的数据结构。每一个xxx_cache_path都会创建一个ngx_http_file_cache_t.
阅读全文…

这次主要来看upstream的几个相关的hook函数。

首先要知道，对于upstream，同时有两个连接，一个时client和nginx，一个是nginx和upstream，这个时候就会有两个回调，然后上篇blog中，我们能看到在upstream中，会改变read_event_handler和write_event_handler,不过这里有三个条件，分别是
1 没有使用cache，
2 不忽略client的提前终止
3 不是post_action

//条件赋值
    if (!u->store && !r->post_action && !u->conf->ignore_client_abort) {
//然后给读写handler赋值
        r->read_event_handler = ngx_http_upstream_rd_check_broken_connection;
        r->write_event_handler = ngx_http_upstream_wr_check_broken_connection;
    }

阅读全文…

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