josevalim
Proposing Registry
Hello everyone,
I would like to propose the addition of the Registry project to Elixir:
The Registry project is a local and scalable key-value process storage in Elixir. It encapsulates 3 known use cases:
- Process registry: to register process with dynamic names. Often Elixir developers need to rely on gproc or other tools.
- Code dispatching: dispatch a module/function associated to a given key
- PubSub implementation: send messages to local processes registered under a given topic
There are probably other use cases waiting to be discovered. 
You can learn more in the documentation:
http://elixir-lang.org/docs/registry/
The project clocks only 700LOC with documentation and performs well. We have extracted, improved and generalized the patterns from Phoenix.PubSub, the implementation used to manage and publish messages to 2 million subscribers.
When benchmarking thousands of processes registering serially, it is twice slower than local atoms, albeit 33% faster than gproc. On concurrent cases, it distributes well across all cores, becoming only 15% slower than local atoms, and 3x faster than gproc on a machine with two cores (gproc seems to be serial with its default configurations so the difference will be even bigger on more cores).
Please give it a try and let us know what you think.
Most Liked
josevalim
The Registry has been merged into Elixir master.
josevalim
This is local, the OTP one is distributed. You shouldn’t use the OTP one to store local data, as looking up or storing information may require messages across nodes.
On my benchmarks, the use of partitions have only been justified for the pubsub/dispatch use cases. For the unique registry, I couldn’t find a case yet where increasing the number of partitions matter. However, my current machine has only 2 cores. Maybe a partitioned unique registry may matter on machines with 16+ cores.
:gproc is a great project, albeit I find its API confusing (YMMV). If you asked me about a registry in Elixir six months ago, the answer would likely be no. So what has changed?
- I confirmed with the OTP team they have no plans to tackle a local registry
- While working on a separate project wth @chrismccord, we realized we could generalize the PubSub implementation while keeping the scalability aspects of Phoenix.PubSub
- The generalization of PubSub made it useful for at least 2 other common cases: :via lookups and module/function dispatching. :via lookups is a frequently required feature. Plus I am using module/function dispatching to replace GenEvent in another app and we will explore it instead of GenEvent in Logger too.
Being faster than gproc is a perk, although the registry was designed to scale with multiple cores. Work in the registry is always done on the client, there is no centralized entity, and that’s another useful pattern to have in hand.
In other words, there isn’t a single reason. We found a generic solution that is performant and scalable and our reaction is that it can be very useful as part of the language.
josevalim
Its API is quite simpler than gproc’s. There is no support for distribution as well, it is by definition local. One reason why we are hesitant on tackling any distributed registry as part of Elixir is because such is already part of the OTP team plans.
Popular in News
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Enabling companies to succeed by building software people love.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"