异步gen_server进行port访问时性能严重下降的原因和应对方法（二）成因
上文介绍了简单的问题场景，现在来分析下产生的原因。
consumer进程里面调用file:write和gen_tcp:send来处理消息：
handle_msg(Type, Msg, #state{file = File, socket = Socket}) when is_binary(Msg) ->
case Type of
file -> file:write(File, Msg);
net -> gen_tcp:send(Socket, Msg)
end;
handle_msg(Type, Msg, State) ->
handle_msg(Type, term_to_binary(Msg), State).
这两个函数都是通过erlang的port体系实现的：
file:open返回一个文件描述符，如果选项包含raw，那么这个描述符将是一个record，定义为：
kernel/include/file.hrl
-record(file_descriptor,
{module :: module(), % Module that handles this kind of file
data :: term()}). % Module dependent data
通常为#file_descriptor{module = prim_file, data = {Port, Number}}，其中Port为文件对应的erlang port，Number为文件在erlang虚拟机进程中的描述符，原进程内部调用prim_file的各个接口；
如果选项不包含raw，这个描述符为pid()，这个描述符Pid对应了一个file_io_server进程，该进程代理原进程调用prim_file的各个接口；
gen_tcp:connect返回一个套接字描述符，这个套接字本身就是一个erlang port。
在erlang虚拟机中，文件对应的port_driver为efile，描述符为efile_driver_entry，而tcp套接字对应的port_driver为tcp_inet，描述符为tcp_inet_driver_entry。
通过port体系实现的接口，都需要先打开port，在实现具体功能时，都需要两步动作完成一个请求：
erlang:port_command(Port, Data).
receive
{MsgType, MsgBody} -> handle_port_return(MsgType, MsgBody)
end.
上述动作都需要在调用者进程中完成。
例如，file:write最终定位到prim_file:write，其实现如下：
prim_file.erl
write(#file_descriptor{module = ?MODULE, data = {Port, _}}, Bytes) ->
case drv_command(Port, [?FILE_WRITE,Bytes]) of
{ok, _Size} ->
ok;
Error ->
Error
end.
drv_command(Port, Command) -> drv_command(Port, Command, undefined).
drv_command(Port, Command, R) when is_binary(Command) ->
drv_command(Port, Command, true, R);
drv_command(Port, Command, R) ->
try erlang:iolist_size(Command) of
_ -> drv_command(Port, Command, true, R)
catch error:Reason -> {error, Reason}
end.
drv_command(Port, Command, Validated, R) when is_port(Port) ->
try erlang:port_command(Port, Command) of
true -> drv_get_response(Port, R)
catch
error:badarg when Validated -> {error, einval};
error:badarg ->
try erlang:iolist_size(Command) of
_ -> {error, einval}
catch error:_ -> {error, badarg}
end;
error:Reason -> {error, Reason}
end;
drv_command({Driver, Portopts}, Command, Validated, R) ->
case drv_open(Driver, Portopts) of
{ok, Port} ->
Result = drv_command(Port, Command, Validated, R),
drv_close(Port),
Result;
Error ->
Error
end.
drv_get_response(Port, R) when is_list(R) ->
case drv_get_response(Port) of
ok ->
{ok, R};
{ok, Name} ->
drv_get_response(Port, [Name|R]);
Error ->
Error
end;
drv_get_response(Port, _) ->
drv_get_response(Port).
drv_get_response(Port) ->
erlang:bump_reductions(100),
receive
{Port, {data, [Response|Rest] = Data}} ->
try translate_response(Response, Rest)
catch
error:Reason ->
{error, {bad_response_from_port, Data, {Reason, erlang:get_stacktrace()}}}
end;
{'EXIT', Port, Reason} -> {error, {port_died, Reason}}
end.
而gen_tcp:send最终定位到prim_inet:send，其实现如下：
send(S, Data, OptList) when is_port(S), is_list(OptList) ->
?DBG_FORMAT("prim_inet:send(~p, ~p)~n", [S,Data]),
try erlang:port_command(S, Data, OptList) of
false -> % Port busy and nosuspend option passed
?DBG_FORMAT("prim_inet:send() -> {error,busy}~n", []),
{error,busy};
true ->
receive
{inet_reply,S,Status} ->
?DBG_FORMAT("prim_inet:send() -> ~p~n", [Status]),
Status
end
catch
error:_Error ->
?DBG_FORMAT("prim_inet:send() -> {error,einval}~n", []),
{error,einval}
end.
send(S, Data) ->
send(S, Data, []).
他们都遵从了上面的编写模式。这个模式看起来并没有什么，但是应用在异步环境里面，却会引起一些问题。
上述模式最根本的问题在于，port发送完命令后，紧接着进行了一次receive，而该receive过程中包含了一个match过程，这个match过程是对进程的消息队列进行遍历，直到找到可以匹配到的消息。
为了更清晰的看清楚这个问题，编写两段段简单的代码，使用erlc +"'S'" x.erl编译，生成它们的抽象码：
receive_match() ->
receive
{Type, Data} -> {Type, Data}
end.
receive_fetch() ->
receive
Msg -> Msg
end.
抽象码为：
01{function, receive_match, 0, 2}.
02 {label,1}.
03 {func_info,{atom,rc},{atom,receive_match},0}.
04 {label,2}.
05 {loop_rec,{f,4},{x,0}}.
06 {test,is_tuple,{f,3},[{x,0}]}.
07 {test,test_arity,{f,3},[{x,0},2]}.
08 {get_tuple_element,{x,0},0,{x,1}}.
09 {get_tuple_element,{x,0},1,{x,2}}.
10 remove_message.
11 {test_heap,3,3}.
12 {put_tuple,2,{x,0}}.
13 {put,{x,1}}.
14 {put,{x,2}}.
15 return.
16 {label,3}.
17 {loop_rec_end,{f,2}}.
18 {label,4}.
19 {wait,{f,2}}.
20
21{function, receive_fetch, 0, 6}.
22 {label,5}.
23 {func_info,{atom,rc},{atom,receive_fetch},0}.
24 {label,6}.
25 {loop_rec,{f,7},{x,0}}.
26 remove_message.
27 return.
28 {label,7}.
29 {wait,{f,6}}.
首先看receive_match的抽象码，其抽象码解释如下：
05 loop_rec指令接收消息，若进程消息队列没有消息，跳至{label,4}处wait，若有消息，将消息移动到进程堆上，绑定到变量{x,0}
06 测试消息是否为元组tuple，若不是跳至{label,3}处
07 测试消息是否为二元元组，若不是跳至{label,3}处
08-09 此时消息已经匹配，可以做后续处理，将元组的两个元绑定到{x,1}和{x,2}上
10 消息已经匹配，将其从消息队列中移除
11-15 正常处理流程
16-17 此处表示，消息队列中有消息，但是并不是最近一次receive需要的消息，此时要做的是将该消息放回到进程消息队列上，并跳转回05的{label,2}处重新取下一条消息
18-19 此处表示，消息队列中没有消息，需要重新跳转回05的{label,2}处取下一条消息
这里可以发现，receive_match函数需要扫描一遍进程消息队列，从中取出符合要求的消息；
接着看receive_fetch的抽象码，其抽象码解释如下：
24-29 若消息队列中没有消息，则继续等待，若有消息，则取出消息，将消息移动到进程堆上，绑定到变量{x,0}；
这里可以发现，receive_fetch不会扫描进程消息队列，直接取出下一条消息。
上述抽象码对应的erlang虚拟机c代码此处不再分析，其执行过程即如上所述，有兴趣的读者可以自行查阅。
这里便可以解释之前场景的问题了：
consumer的进程内部调用file:write或gen_tcp:send，然后将形成一个receive_match的模式，遍历进程消息队列，然后取出需要的消息；另一方面，生产者却没有任何顾忌的往consumer进程中投递消息，如果处理（也即调用file:write或gen_tcp:send）速度慢于消息投递速度（通常情况下总是如此，gen_server:cast的qps在本地可以轻松达到40-80w），则consumer的消息队列将不断增大，receive_match模式却仍然需要遍历整个消息队列，从而导致处理速度进一步下降，消息队列进一步增大，陷入一个恶性循环。
实际应用中，也有会遭遇这种典型的场景：进程允许异步投递， 但进程内部有调用port（receive_match）的模式出现 。
未完待续...