Skip to content

Commit 01f8eab

Browse files
committed
Prepare for a 1.6.0 release
1 parent 828dedd commit 01f8eab

File tree

2 files changed

+35
-24
lines changed

2 files changed

+35
-24
lines changed

README.md

+34-23
Original file line numberDiff line numberDiff line change
@@ -8,32 +8,14 @@ Erlang and Elixir make it very easy to send messages between processes even acro
88
- Sending a message to many PIDs across the network also copies the message across the network that many times.
99
- Send calls cost about 70 µs/op so doing them in a loop eventually gets too expensive.
1010

11-
[Discord](https://discordapp.com) runs a single `GenServer` per Discord server and some of these have over 30,000 PIDs connected
12-
to them from many different Erlang nodes. Increasingly we noticed some of them getting behind on processing their message queues
13-
and the culprit was the cost of 70 µs per `send/2` call multiplied by connected sessions. How could we solve this?
11+
[Discord](https://discordapp.com) runs a single `GenServer` per Discord server and some of these ~100,000 PIDs connected to them from many different Erlang nodes. Increasingly we noticed some of them getting behind on processing their message queues and the culprit was the cost of 70 µs per `send/2` call multiplied by connected sessions. How could we solve this?
1412

15-
Inspired by a [blog post](http://www.ostinelli.net/boost-message-passing-between-erlang-nodes/) about boosting performance of
16-
message passing between nodes, Manifold was born. Manifold distributes the work of sending messages to the remote nodes of the
17-
PIDs, which guarantees that the sending processes at most only calls `send/2` equal to the number of involved remote nodes.
18-
Manifold does this by first grouping PIDs by their remote node and then sending to `Manifold.Partitioner` on each of those nodes.
19-
The partitioner then consistently hashes the PIDs using `:erlang.phash2/2`, groups them by number of cores, sends to child
20-
workers, and finally those workers send to the actual PIDs. This ensures the partitioner does not get overloaded and still provides
21-
the linearizability guaranteed by `send/2`.
13+
Inspired by a [blog post](http://www.ostinelli.net/boost-message-passing-between-erlang-nodes/) about boosting performance of message passing between nodes, Manifold was born. Manifold distributes the work of sending messages to the remote nodes of the PIDs, which guarantees that the sending processes at most only calls `send/2` equal to the number of involved remote nodes. Manifold does this by first grouping PIDs by their remote node and then sending to `Manifold.Partitioner` on each of those nodes. The partitioner then consistently hashes the PIDs using `:erlang.phash2/2`, groups them by number of cores, sends to child workers, and finally those workers send to the actual PIDs. This ensures the partitioner does not get overloaded and still provides the linearizability guaranteed by `send/2`.
2214

23-
The results were great! We observed packets/sec drop by half immediately after deploying. The Discord servers in question also
24-
were finally able to keep up with their message queues.
15+
The results were great! We observed packets/sec drop by half immediately after deploying. The Discord servers in question also were finally able to keep up with their message queues.
2516

2617
![Packets Out Reduction](priv/packets.png)
2718

28-
There is an optional and experimental `:offload` send mode which offloads on the send side the `send/2` calls to the receiving
29-
nodes to a pool of `Manifold.Sender` processes. To maintain the linearizability guaranteed by `send/2`, the same calling process
30-
always offloads the work to the same `Manifold.Sender` process. The size of the `Manifold.Sender` pool is configurable. This send
31-
mode is optional because its benefits are workload dependent. For some workloads, it might degrade overall performance. Use with
32-
caution.
33-
34-
Caution: To maintain the linearizability guaranteed by `send/2`, do not mix calls to Manifold with and without offloading. Mixed
35-
use of the two different send modes to the same set of receiving nodes would break the linearizability guarantee.
36-
3719
## Usage
3820

3921
Add it to `mix.exs`
@@ -51,8 +33,36 @@ Manifold.send(self(), :hello)
5133
Manifold.send([self(), self()], :hello)
5234
```
5335

54-
To use the experimental `:offload` send mode, make sure the `Manifold.Sender` pool size is appropriate for the
55-
workload:
36+
### Options
37+
38+
When using Manifold there are two performance options you can choose to enable.
39+
40+
#### pack_mode
41+
42+
By default Manifold will send the message using vanilla [External Term Format](https://www.erlang.org/doc/apps/erts/erl_ext_dist.html). If `pack_mode` is not specified or is set to `nil` or `:etf` then this mode will be used.
43+
44+
When messages are very large `pack_mode` can be set to `:binary` and this will cause Manifold to ensure that the term is only converted into [External Term Format](https://www.erlang.org/doc/apps/erts/erl_ext_dist.html) once. The encoding will happen in the sending process (either the calling process or a `Manifold.Sender`, see `send_mode` for additional details) and will
45+
46+
The `:binary` optimization works best with large and deeply nested messages that are being sent to PIDs across multiple nodes. Without the optimization, a message sent to N nodes will have to be translated into [External Term Format](https://www.erlang.org/doc/apps/erts/erl_ext_dist.html) N times. With large data structures, this operation can be expensive. With the optimization enabled, the encoding into binary happens once and then over distribution each sending process only needs to transmit the binary.
47+
48+
To send using the binary pack mode, just add the `pack_mode` argument
49+
50+
```elixir
51+
Manifold.send(self(), :hello, pack_mode: :binary)
52+
```
53+
54+
#### send_mode
55+
56+
By default Manifold will send the message over the network from the caller process. If `send_mode` is not specified then the default behavior of sending from the caller process will be used.
57+
58+
When messages are very large, `send_mode` can be set to `:offload` which offloads the send from the calling process to a pool of `Manifold.Sender` processes. To maintain the linearizability guaranteed by `send/2`, the same calling process
59+
always offloads the work to the same `Manifold.Sender` process. The size of the `Manifold.Sender` pool is configurable.
60+
61+
This send mode is optional because its benefits are workload dependent. The optimization works best when the cost of sending a message to a local process < the cost of sending a message over distribution. This is most common for messages that are very large in size. For some workloads, it might degrade overall performance. Use with caution.
62+
63+
Caution: To maintain the linearizability guaranteed by `send/2`, do not mix calls to Manifold with and without offloading. Mixed use of the two different send modes to the same set of receiving nodes would break the linearizability guarantee.
64+
65+
To use the `:offload` send mode, make sure the `Manifold.Sender` pool size is appropriate for the workload:
5666

5767
```elixir
5868
config :manifold, senders: <size>
@@ -65,6 +75,7 @@ Manifold.send(self(), :hello, send_mode: :offload)
6575
```
6676

6777
### Configuration
78+
6879
Manifold takes a single configuration option, which sets the module it dispatches to actually call send. The default
6980
is GenServer. To set this variable, add the following to your `config.exs`:
7081

mix.exs

+1-1
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ defmodule Manifold.Mixfile do
44
def project do
55
[
66
app: :manifold,
7-
version: "1.5.1",
7+
version: "1.6.0",
88
elixir: "~> 1.5",
99
build_embedded: Mix.env == :prod,
1010
start_permanent: Mix.env == :prod,

0 commit comments

Comments
 (0)