[erlang-questions] How do mailboxes relate to reduction counts?

[Michel Boaventura]

On Erlang Programming - A Concurrent Approach to Software Development the
authors (Francesco Cesarini and Simon Thompson) explain this:

Processes are said to act as bottlenecks when, over time, they are sent
> messages at a faster rate than they can handle them, resulting in large
> mailbox queues. How do processes with many messages in their inbox behave?
> The answer is badly.
> First, the process itself, through a selective receive, might match only a
> specific type of message. If the message is the last one in the mailbox
> queue, the whole mailbox has to be traversed before this message is
> successfully matched. This causes a performance penalty that is often
> visible through high CPU consumption.
> Second, processes sending messages to a process with a long message queue
> are penalized by increasing the number of reductions it costs to send the
> message. This is an attempt by the runtime system to allow processes with
> long message queues to catch up by slowing down the processes sending the
> messages in the first place. The latter bottleneck often manifests itself
> in a reduction of the overall throughput of the system.
> The only way to discover whether there are any bottlenecks is to observe
> the throughput and message queue buildup when stress-testing the system.
> Simple remedies to message queue problems can be achieved by optimizing the
> code and fine-tuning the operating system and VM settings.
> Another way to slow down message queue buildups is by suspending the
> processes generating the messages until they receive an acknowledgment that
> the message they have sent has been received and handled, effectively
> creating a synchronous call. Replacing asynchronous calls with synchronous
> ones will reduce the maximum throughput of the system when running under
> heavy load, but never as much as the penalty paid when message queues start
> building up. Where bottlenecks are known to occur, it is safer to reduce
> the throughput by introducing synchronous calls, and thus guaranteeing a
> constant throughput of requests in the system with no degradation of
> service under heavy loads.


So I think the idea behind this is to give the overloaded process a change
to keep up with the other ones.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170305/39a48b61/attachment.htm>