gpt4 book ai didi

erlang - 为什么要这样设计?

转载 作者:行者123 更新时间:2023-12-03 21:43:49 25 4
gpt4 key购买 nike

我在使用啤酒时遇到问题。
在更大的源代码中,lager_backend_throttle.erl 文件。

handle_event({log, _Message},State) ->
{message_queue_len, Len} = erlang:process_info(self(), message_queue_len),
case {Len > State#state.hwm, State#state.async} of
{true, true} ->
%% need to flip to sync mode
lager_config:set(async, false),
{ok, State#state{async=false}};
{false, false} ->
%% need to flip to async mode
lager_config:set(async, true),
{ok, State#state{async=true}};
_ ->
%% nothing needs to change
{ok, State}
end;

当 message_queue_len 大于 Threshold 时,它会翻转到同步模式。

当 message_queue_len 小于 Thershold 时,它将翻转到异步模式。

我认为当消息太多时,应该将模式更改为异步以更快地处理消息。为什么要这样设计?

我猜的原因是message_queue有限制长度,如果消息太多,进程可能会崩溃。那么通过改变发送模式来更大地降低发送消息的速度?

最佳答案

我在github上找到了答案。

在lager 2.0 之前,lager 核心的gen_event 纯粹以同步模式运行。异步模式速度更快,但无法防止消息队列过载。在lager 2.0 中, gen_event 采用混合方法。它轮询自己的邮箱大小并根据邮箱大小在同步和异步之间切换消息传递。

{异步阈值,20},
{async_threshold_window, 5}
这将使用异步消息,直到邮箱超过 20 条消息,此时将使用同步消息,并在大小减少到 20 - 5 = 15 时切换回异步。

如果您希望禁用此行为,只需将其设置为“未定义”。它默认为一个较低的数字,以防止邮箱快速增长超出限制并导致问题。一般来说,啤酒应该尽快处理消息,所以落后 20 应该是相对特殊的。

如果您想限制 error_logger 允许的每秒消息数,如果您想在许多相关进程崩溃时承受大量消息,这是一个好主意,您可以设置一个限制:

{error_logger_hwm, 50}
最好保持这个数字很小。

关于erlang - 为什么要这样设计?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23263890/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com