Yeah, I thought about comparing with Syn as well, though I agree with @josevalim that a direct comparison is not really appropriate. But just to satisfy our curiosity:
Bottom line: on a standalone node, Syn is always a bit slower than Gproc, but at high concurrency it is faster than the standard Erlang process registry (as well as Registry without partitions).
Registry has been updated to v0.3.0 with:
The last two features should make the registry more extensible. Listeners allows you to give a named process when the registry is started that will receive events whenever a process registers or unregisters a key. You could use those features to add Await support to the registry or even use the registry as a pool. We have added an example of using the registry as a sojourn pool to the examples directory. The pool is an example, do not use it in production:
https://github.com/elixir-lang/registry/blob/master/examples/sojourn.exs
The pool above measures the sojourn time, which is how long messages stay in each pooled process queue. That provides an idea of how fast processes are responding. Whenever there is a dispatch, we pick two random pooled processes and choose the one with the most recent reply and smaller sojourn time.
The pool itself works by starting a worker and a registry. The worker is a listener of the registry and a supervisor guarantees that both are restarted in case any of crashes. Whenever a new process is added to the registry, the worker is notified and starts sending sampling messages to that process which updates its own entry in case of crashes.
I hope it serves as inspiration for playing with the registry for other use cases.
Definitely like the changes. 
Btw, @voltone has re-ran the benchmarks, including more partitions and parameters. For those interested, please check out the updated spreadsheet:
Thank you @voltone!
Looks like the optimal performance is achieved when having a partition per core. Is this correct?
Yes but it doesnât mean having a partition per core is necessarily the way to go. If you donât expect an intensive workload, using 4 or 8 partitions for 40 cores would be fine.
Being the most pessimistic, I would do a factor of 0.25 on the number of cores. So for 40 cores, I would do 10 partitions. Like this: System.schedulers_online |> div(4) |> max(1).
The Registry has been merged into Elixir master.
Hey José,
I was taking a look at the code and was puzzled over two things:
Is there a convention in place for cases like this?
Because the name is not optional on this case.
No conventions as far as I know.
Does anyone know where can I find more info on the OTP Teamâs plans on a distributed registry?
Doesnât global predate the Elixir Registry and this whole thread by years? I think that @josevalim was referring to something else. Still, I couldnât see reference to any new work in progress in the global docs.
The project was briefly mentioned at the conference in Stockholm last year:
Itâs the distributed hash table mentioned as an alternative to Global on the last slide of âNews from the OTP team.
There was also this tidbit:
http://www.erlang-factory.com/sfbay2017/christopher-meiklejohn.html
Recently, attempts have been made to resolve the problems of Distributed Erlang: SD-Erlang and Ericssonâs planned port of global to the Kademlia DHT are focused on reducing the amount of information that each node in the global registry needs to replicate, but that only temporarily mitigates the problem.
Thatâs about all Iâve heard personally.
There is a talk about the DHT plans here:
Thank you both, that was very helpful!
© Copyright Elixir Forum | Terms | Privacy & Cookies
