-rw-r–r– 1 root root 183741 2010-05-21 11:43 erlang.el

-rw-r–r– 1 root root  10059 2010-05-21 11:43 erlang-eunit.el

-rw-r–r– 1 root root   3452 2010-05-21 11:43 erlang-start.el

-rw-r–r– 1 root root   1611 2010-05-21 11:43 README

-rw-r–r– 1 root root  12834 2010-05-21 11:43 test.erl.indented

-rw-r–r– 1 root root  11877 2010-05-21 11:43 test.erl.orig

恩，十分简单方便，记录以备查询。

上代码：

-module(mnesia_read_test).

-export([start/0, init_data/0, start2/0]).

-record(r_test, {id, name}).

start() ->

        statistics(wall_clock),

    statistics(runtime),

        read(),

        {_, Time1} = statistics(wall_clock),

    {_, Time2} = statistics(runtime),

    io:format("times:~p, wall_clock ~p, runtime:~p", [100000, Time1, Time2]).

start2() ->

        statistics(wall_clock),

    statistics(runtime),

        read2(),

        {_, Time1} = statistics(wall_clock),

    {_, Time2} = statistics(runtime),

    io:format("times:~p, wall_clock ~p, runtime:~p", [100000, Time1, Time2]).

read() ->

        dirty_read(100000).

dirty_read(0) ->

    ok;

dirty_read(N) ->

    mnesia:dirty_read(r_test, N),

    dirty_read(N-1).

read2() ->

        t_read(100000).

t_read(0) ->

        ok;

t_read(N) ->

        mnesia:transaction( fun() -> mnesia:read(r_test, N) end),

        t_read(N-1).

init_data() ->

    mnesia:stop(),

    mnesia:create_schema([node()]),

    mnesia:start(),

    mnesia:create_table(r_test, [

                               {attributes, record_info(fields, r_test)},

                               {record_name, r_test},

                               {disc_copies, [node()]}

                               ]),

    mnesia:transaction(

        fun() ->

            t_write(10000)

        end

    ).

t_write(0) ->

    ok;

t_write(N) ->

    Name = lists:append(["name_", N]),

    R = #r_test{id=N, name=Name},

    mnesia:write(R),

    t_write(N-1).

两种情况都循环读了10W次，连续测试10次，机器配置为：

Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz      2*4核

12G内存

事务读测试结果：

times:100000, wall_clock 4168, runtime:4160ok

times:100000, wall_clock 4296, runtime:4250ok

times:100000, wall_clock 4338, runtime:4290ok

times:100000, wall_clock 4310, runtime:4260ok

times:100000, wall_clock 4330, runtime:4280ok

times:100000, wall_clock 4342, runtime:4270ok

times:100000, wall_clock 4399, runtime:4310ok

times:100000, wall_clock 4366, runtime:4310ok

times:100000, wall_clock 4378, runtime:4310ok

times:100000, wall_clock 4429, runtime:4330ok

一次读的时间大于为44us，这还是在没有分布式的情况下的测试结果，如果是在分布式环境中，由于网络IO和远程加锁，性能会更差。

脏读测试结果：

times:100000, wall_clock 128, runtime:130ok

times:100000, wall_clock 126, runtime:120ok

times:100000, wall_clock 124, runtime:120ok

times:100000, wall_clock 126, runtime:120ok

times:100000, wall_clock 127, runtime:130ok

times:100000, wall_clock 125, runtime:130ok

times:100000, wall_clock 125, runtime:120ok

times:100000, wall_clock 127, runtime:120ok

times:100000, wall_clock 128, runtime:130ok

times:100000, wall_clock 127, runtime:130ok

和ets的性能几乎一样，一次读取的消耗大约1.2us，和事务相比快了几十倍。追踪脏读源码到mnesia_lib.erl中：

db_get(Tab, Key) ->

    db_get(val({Tab, storage_type}), Tab, Key).

db_get(ram_copies, Tab, Key) -> ?ets_lookup(Tab, Key);

db_get(disc_copies, Tab, Key) -> ?ets_lookup(Tab, Key);

db_get(disc_only_copies, Tab, Key) -> dets:lookup(Tab, Key).

呵呵，果然是ets直接操作。

之前一直因为QQ的问题无法转过来，现在有了webqq和linuxqq，暂时可以尝试下了。

(最近挺忙，都没时间写点啥)

gen_server是OTP中的一个重要组成，在开发中出现的频率相当高。弄明白这一块的，对于gen_server的使用有着相当好的帮忙。下面多数为代码。

从start_link开始：

gen_server.erl

start_link(Name, Mod, Args, Options) ->

gen:start(?MODULE, link, Name, Mod, Args, Options).

跳到gen.erl，这里的GenMod值为gen_server，LinkP为link

start(GenMod, LinkP, Name, Mod, Args, Options) ->

    case where(Name) of

undefined ->

    do_spawn(GenMod, LinkP, Name, Mod, Args, Options);

Pid ->

    {error, {already_started, Pid}}

end.

再跳：

do_spawn(GenMod, link, Name, Mod, Args, Options) ->

    Time = timeout(Options),

    proc_lib:start_link(?MODULE, init_it,

[GenMod, self(), self(), Name, Mod, Args, Options],

Time,

spawn_opts(Options));

跳到proc_lib.erl文件：

start_link(M,F,A,Timeout,SpawnOpts) when is_atom(M), is_atom(F), is_list(A) ->

    Pid = ?MODULE:spawn_opt(M, F, A, ensure_link(SpawnOpts)),

sync_wait(Pid, Timeout).

注意这里有个等待返回，之后需要proc_lib:init_ack来返回消息。

spawn_opt(M, F, A, Opts) when is_atom(M), is_atom(F), is_list(A) ->

    Parent = get_my_name(),

    Ancestors = get_ancestors(),

    check_for_monitor(Opts),

    erlang:spawn_opt(?MODULE, init_p, [Parent,Ancestors,M,F,A], Opts).

这里调用proc_lib模块的init_p方法：

-spec init_p(pid(), [pid()], function()) -> term().

init_p(Parent, Ancestors, Fun) when is_function(Fun) ->

    put('$ancestors', [Parent|Ancestors]),

    {module,Mod} = erlang:fun_info(Fun, module),

    {name,Name} = erlang:fun_info(Fun, name),

    {arity,Arity} = erlang:fun_info(Fun, arity),

    put('$initial_call', {Mod,Name,Arity}),

    try

Fun()

    catch

Class:Reason ->

    exit_p(Class, Reason)

    end.

-spec init_p(pid(), [pid()], atom(), atom(), [term()]) -> term().

init_p(Parent, Ancestors, M, F, A) when is_atom(M), is_atom(F), is_list(A) ->

    put('$ancestors', [Parent|Ancestors]),

    put('$initial_call', trans_init(M, F, A)),

    init_p_do_apply(M, F, A).

init_p_do_apply(M, F, A) ->

    try

apply(M, F, A) 

    catch

Class:Reason ->

    exit_p(Class, Reason)

end.

有点晕头了吧，MFA是什么呢？如下：

gen, init_it,

[gen_server, self(), self(), Name, Mod, Args, Options]

这里的Name, Mod, Args是我们自己的注册名，模块名、参数。

调回init：

init_it(GenMod, Starter, Parent, Name, Mod, Args, Options) ->

    case name_register(Name) of

true ->

    init_it2(GenMod, Starter, Parent, Name, Mod, Args, Options);

{false, Pid} ->

    proc_lib:init_ack(Starter, {error, {already_started, Pid}})

    end.

init_it2(GenMod, Starter, Parent, Name, Mod, Args, Options) ->

    GenMod:init_it(Starter, Parent, Name, Mod, Args, Options).

ok，又回到gen_server了。跳转到gen_server的init_it：

init_it(Starter, self, Name, Mod, Args, Options) ->

    init_it(Starter, self(), Name, Mod, Args, Options);

init_it(Starter, Parent, Name0, Mod, Args, Options) ->

    Name = name(Name0),

    Debug = debug_options(Name, Options),

    case catch Mod:init(Args) of

{ok, State} ->

    proc_lib:init_ack(Starter, {ok, self()}),      

    loop(Parent, Name, State, Mod, infinity, Debug);

{ok, State, Timeout} ->

    proc_lib:init_ack(Starter, {ok, self()}),      

    loop(Parent, Name, State, Mod, Timeout, Debug);

{stop, Reason} ->

    %% For consistency, we must make sure that the

    %% registered name (if any) is unregistered before

    %% the parent process is notified about the failure.

    %% (Otherwise, the parent process could get

    %% an 'already_started' error if it immediately

    %% tried starting the process again.)

    unregister_name(Name0),

    proc_lib:init_ack(Starter, {error, Reason}),

    exit(Reason);

ignore ->

    unregister_name(Name0),

    proc_lib:init_ack(Starter, ignore),

    exit(normal);

{'EXIT', Reason} ->

    unregister_name(Name0),

    proc_lib:init_ack(Starter, {error, Reason}),

    exit(Reason);

Else ->

    Error = {bad_return_value, Else},

    proc_lib:init_ack(Starter, {error, Error}),

    exit(Error)

end.

呵呵，苦尽甘来，终于来到loop主循环了。 gen_server的消息怎么来的？就是这个loop不断地取出消息、decode_msg、再loop来不断从消息队列中取出消息的。这个主循环就是我们的gen_server进程了。

loop(Parent, Name, State, Mod, hibernate, Debug) ->

    proc_lib:hibernate(?MODULE,wake_hib,[Parent, Name, State, Mod, Debug]);

loop(Parent, Name, State, Mod, Time, Debug) ->

    Msg = receive

      Input ->

    Input

  after Time ->

  timeout

  end,

    decode_msg(Msg, Parent, Name, State, Mod, Time, Debug, false).

decode_msg(Msg, Parent, Name, State, Mod, Time, Debug, Hib) ->

    case Msg of

{system, From, Req} ->

    sys:handle_system_msg(Req, From, Parent, ?MODULE, Debug,

  [Name, State, Mod, Time], Hib);

{'EXIT', Parent, Reason} ->

    terminate(Reason, Name, Msg, Mod, State, Debug);

_Msg when Debug =:= [] ->

    handle_msg(Msg, Parent, Name, State, Mod);

_Msg ->

    Debug1 = sys:handle_debug(Debug, {?MODULE, print_event}, 

      Name, {in, Msg}),

    handle_msg(Msg, Parent, Name, State, Mod, Debug1)

    end.

这里我们就看到了terminate的自动回调（如果设置了trap_exit）。

handle_msg中处理了handle_call类型的调用， 而handle_cast和handle_info则由dispatch来处理：

dispatch({'$gen_cast', Msg}, Mod, State) ->

    Mod:handle_cast(Msg, State);

dispatch(Info, Mod, State) ->

Mod:handle_info(Info, State).

handle_msg处理handle_call也很简单，回调我们的handle_call方法：

handle_msg({'$gen_call', From, Msg}, Parent, Name, State, Mod, Debug) ->

case catch Mod:handle_call(Msg, From, State) of

……

至此，整个gen_server的运行流程就清楚了（晕的话，多看几遍）。

回头再来看看terminate的处理

terminate(Reason, Name, Msg, Mod, State, Debug) ->

    case catch Mod:terminate(Reason, State) of

{'EXIT', R} ->

    error_info(R, Name, Msg, State, Debug),

    exit(R);

_ ->

    case Reason of

normal ->

    exit(normal);

shutdown ->

    exit(shutdown);

{shutdown,_}=Shutdown ->

    exit(Shutdown);

_ ->

    error_info(Reason, Name, Msg, State, Debug),

    exit(Reason)

    end

end.

这里terminate在回调了gen_server的terminate函数后，又exit了一次，目的是为了产生一个'EXIT'消息给supervisor，以便让supervisor做相应的重启策略。

一、基本概念

在Erlang中，通过两个概念管理错误事情：事件管理器(event manager)和事件处理句柄(event handles)。通常各种错误、警告和消息事件都会有Erlang运行时系统发送给事件管理器。在Erlang中，默认的事情管理器为error logger，其进程名注册为error_logger。默认情况下error_logger把这些事件直接输出到控制台上。

       在系统启动的一开始，error_logger只有一个简单的事件处理句柄，该处理句柄只是做缓冲和原始格式的打印操作。查看error_logger的源码，可以看到其启动过程如下：

-spec start() -> {'ok', pid()} | {'error', any()}.

start() ->

    case gen_event:start({local, error_logger}) of

    {ok, Pid} ->

        simple_logger(?buffer_size),

        {ok, Pid};

    Error -> Error

    end.

-spec start_link() -> {'ok', pid()} | {'error', any()}.

start_link() ->

    case gen_event:start_link({local, error_logger}) of

    {ok, Pid} ->

        simple_logger(?buffer_size),

        {ok, Pid};

    Error -> Error

end.

OK，只是简单的注册了一个进程，看看simple_logger的内容：

simple_logger(Buffer_size) when is_integer(Buffer_size) ->

gen_event:add_handler(error_logger, error_logger, Buffer_size).

看来error_logger在一开始的时候除了充当manager，也担当了handler的角色。

在启动的过程中，kernel application使用一个标准的事件处理句柄来代替之前的那个简单版本，这个版本会将输出到控制台的结果做个漂亮的格式化。当然，可以通过kernel的配置选项来修改上述行为，例如将结果输出到文件或者干脆什么都不干（忽略任何event）。口说无凭，还是继续看源码吧：

kernel.erl文件：

start(_, []) ->

    case supervisor:start_link({local, kernel_sup}, kernel, []) of

    {ok, Pid} ->

        Type = get_error_logger_type(),

        error_logger:swap_handler(Type),

        {ok, Pid, []};

    Error -> Error

end.

首先，kernel把自己注册为一个名为kernel_sup的监控树进程，其次立刻就更换了error_logger的处理句柄。go on：

get_error_logger_type() ->

    case application:get_env(kernel, error_logger) of

    {ok, tty} -> tty;

    {ok, {file, File}} when is_list(File) -> {logfile, File};

    {ok, false} -> false;

    {ok, silent} -> silent;

    undefined -> tty; % default value

    {ok, Bad} -> exit({bad_config, {kernel, {error_logger, Bad}}})

end.

代码很容易理解，根据配置来决定以何种方式处理日志。

二、定制Kernel选项

继续接着上面的代码往下走：

swap_handler(tty) ->

    gen_event:swap_handler(error_logger, {error_logger, swap},

              {error_logger_tty_h, []}),

    simple_logger();

swap_handler({logfile, File}) ->

    gen_event:swap_handler(error_logger, {error_logger, swap},

              {error_logger_file_h, File}),

    simple_logger();

swap_handler(silent) ->

    gen_event:delete_handler(error_logger, error_logger, delete),

    simple_logger();

swap_handler(false) ->

ok. % keep primitive event handler as-is

可以看出，如果我们真的希望什么都不做，那么应该传递参数 silent，而不是false，因为false情况下原来的原始处理句柄并没有被移除掉。

打开命令提示符，做个简单的实验(>表示命令提示符)：

实验一，定制为false参数：

> erl -kernel error_logger false  //传递false参数

2> error_logger:error_msg("Haha").  // 尝试产生一个error event

ok{error_logger,{{

2010,2> 3,10},{15,9,1}},"Haha",[]}  //这里是结果

实验二，定制为silent参数：

> erl -kernel error_logger silent  //传递silent 参数

1>  error_logger:error_msg("Haha").

ok   // 看到这里只有ok，没有其他任何信息了！

2>

三、SASL

SASL全称System Architecture Support Libraries，提供如下几个服务：

alarm_handler

overload

rb

release_handler

systools

SASL带有error_logger的事件处理句柄用于格式化SASL错误和crash报告，这些句柄如下：

sasl_report_tty_h   sasl_report_file_h   error_logger_mf_h

细节参考OTP文档可知。

SASL的默认event handler会将crash报告、supervisor和进程报告输出到控制台，如果你希望看到这些信息，那么在erlang启动时需要加上指定的参数以启动sasl。

为了方便日志的查看，通常sasl和其他日志是分开输出的，可以在启动erl时使用如下命令行参数：

-sasl sasl_error_logger {file,"/data/ log/sasl.log"}

四、站在巨人的肩膀上

这里并不打算介绍一个gen_event behavior模块的写法，而是想介绍一个非常强大、成熟的一个日志系统：ejabberd的日志系统。它包含两个部分：

dynamic_compile.erl   动态编译基础模块

ejabberd_logger_h.erl  这是个gen_event behavior模块，可以定制我们写日志的行为

ejabberd_loglevel.h    这个是ejabberd日志系统的精华，可以在运行时动态调节日志的输出级别。

用法很简单：

error_logger:add_report_handler(ejabberd_logger_h, LogPath),

ejabberd_loglevel:set(4) //级别4是info日志

原理很简单，利用code模块的load_binary来实现动态代码替换，但是确实非常强大，可以在需要的时候打开某些特定级别的日志，在系统负载高的时候或者不需要的时候关闭它。

第一组，map和list comprehensions对比，代码如下：

%%map方式

-module(map_test).

-export([start/1]).

start(N) ->

        statistics(runtime),

        erlang:statistics(wall_clock),

        lists:map(fun (X) -> X*X end, lists:seq(1, N)),

        {_, T1} = erlang:statistics(runtime),

        {_, T2} = erlang:statistics(wall_clock),

        io:format("total times: ~p, load time: ~p (~p)", [N, T1, T2]).

%%list comprehensions方式

-module(list_comp_test).

-export([start/1]).

start(N) ->

        statistics(runtime),

        erlang:statistics(wall_clock),

        [X*X || X <- lists:seq(1, N)],

        {_, T1} = erlang:statistics(runtime),

        {_, T2} = erlang:statistics(wall_clock),

        io:format("total times: ~p, load time: ~p (~p)", [N, T1, T2]).

测试N为1000000时结果对比：

结果取得是平均值，可以很明显的看出comprehension方式性能要高。

关于filter，则类似。不再作测试。