Well I’m kind of a beginner in elixir, I come from nodeJs + I don’t know erlang + I have 6 months ahead of me to release a mvp.
I don’t think I’ll have enough time in that timeframe to learn Erlang and develop my own distributed solution…
That’s why I’m looking for a better solution. I could use Horde but read that some people had a lot of problems with it. May be the easy way out for now is just to save data to a DB or use something like redis ?
I can when (if!) its finished/usable - i have restarted 3 times over 5 years, changing the tooling each time.
I have been taking a break from it recently (its more a winter project) so not much to actually share at the moment.
The DSL is very much a ‘in my head’ design rather than something i have coded up yet! Still reading the Metaprogramming elixir book and looking at other coding examples.
It’s very much a play thing so has no schedule for development etc!
Shifters
I don’t know your specific requirements, which makes it hard to suggest anything.
Horde has been around for a while and is widely used, so I believe it performs well for its intended purpose.
You can also try this library, though it hasn’t been battle-tested yet. It’s still in development, but reported bugs will be addressed.
New version 0.3.0-alpha released! 
This release focuses on performance and stability improvements.
Changelog:
### Breaking changes
- `Hook.post_children_start()` now returns: `[{child_id(), result(), pid(), [node()]}]`
- Fixed error handling on process startups and stoppings. Returning more information about the failures and partial successes. Example:`ProcessHub.start_children/3`, `ProcessHub.stop_children/3` with `async_wait: true` now on failures return: `{:error, list_of_failures(), list_of_partial_successes()}`. This does not affect successful operations.
### Added
- Added new option `on_failure: :continue | :rollback` to the `ProcessHub.start_children/3`, `ProcessHub.stop_children/3` functions. This option allows the user to specify what should happen if the operation fails.
### Fixed
- `ProcessHub.Strategy.Redundancy.Replication` was not properly updating the redundancy_signal value on some occasions
due to race condition.
- Fixed issue with `ProcessHub.Janitor` not purging the cache properly when using Gossip protocol.
- State passing on hotswap migration with graceful shutdown fixed.
- Timeout option was not properly used in some cases.
### Changed
- Improved typespecs across the codebase.
- Improved overall performance of start/stop/hotswap migration operations which involved synchronization and large
amount of message passing by using bulk operations.
I also conducted performance tests, and the results show that synchronous operations and migrations are now multiple orders of magnitude faster.
Many potential issues have also been resolved.
There’s still a lot to improve, but here are the results for spawning X distributed processes across a 10-node cluster and stopping them synchronously:
This includes all distribution logic, registry updates, hooks, event dispatching, and result messages for startups and shutdowns etc.
Up until 10k distributed processes in a 10 node cluster the library does okay imo. On average 2.6 seconds to start and stop everything synchronously. After 20k processes the jump is pretty big.
Operating System: Linux
CPU Information: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
Number of Available Cores: 8
Available memory: 31.23 GB
Elixir 1.17.1
Erlang 27.0
JIT enabled: true
Name ips average deviation median 99th %
start_&_stop_processes-0.2.10-alpha 27.43 36.46 ms ±67.09% 33.20 ms 84.64 ms
start_&_stop_processes-0.3.0-alpha 290.82 3.44 ms ±46.01% 3.26 ms 6.51 ms
Memory usage statistics:
Name average deviation median 99th %
start_&_stop_processes-0.2.10-alpha 2.31 MB ±31.30% 2.83 MB 2.83 MB
start_&_stop_processes-0.3.0-alpha 2.08 MB ±36.49% 2.82 MB 2.82 MB
Name ips average deviation median 99th %
start_&_stop_processes-0.2.10-alpha 2.50 400.57 ms ±62.90% 421.35 ms 863.76 ms
start_&_stop_processes-0.3.0-alpha 57.59 17.36 ms ±47.88% 18.34 ms 35.52 ms
Memory usage statistics:
Name average deviation median 99th %
start_&_stop_processes-0.2.10-alpha 31.32 MB ±12.02% 32.24 MB 32.24 MB
start_&_stop_processes-0.3.0-alpha 24.02 MB ±33.93% 32.13 MB 32.13 MB
Name ips average deviation median 99th %
start_&_stop_processes-0.2.10-alpha 0.22 4.49 s ±27.37% 4.42 s 5.76 s
start_&_stop_processes-0.3.0-alpha 7.00 142.89 ms ±50.88% 172.62 ms 297.17 ms
Memory usage statistics:
Name average deviation median 99th %
start_&_stop_processes-0.2.10-alpha 326.14 MB ±0.01% 326.14 MB 326.34 MB
start_&_stop_processes-0.3.0-alpha 248.12 MB ±32.89% 324.90 MB 324.94 MB
Name ips average deviation median 99th %
start_&_stop_processes-0.2.10-alpha 0.0116 1.44 min ±0.00% 1.44 min 1.44 min
start_&_stop_processes-0.3.0-alpha 0.38 2.60 s ±40.86% 3.09 s 3.11 s
Memory usage statistics:
Name average deviation median 99th %
start_&_stop_processes-0.2.10-alpha 3.48 GB
start_&_stop_processes-0.3.0-alpha 3.04 GB ±28.03% 3.47 GB 3.47 GB
At this point the testing the old version took too much time and I just tested the newer version.
Name ips average deviation median 99th %
start_&_stop_processes-0.3.0-alpha 0.193 5.18 s ±111.63% 5.18 s 9.27 s
Memory usage statistics:
Name average deviation median 99th %
start_&_stop_processes-0.3.0-alpha 5.75 GB ±46.80% 5.75 GB 7.65 GB
Name ips average deviation median 99th %
start_&_stop_processes-0.3.0-alpha 0.0277 36.09 s ±0.00% 36.09 s 36.09 s
Memory usage statistics:
Name Memory usage
start_&_stop_processes-0.3.0-alpha 11.47 GB
Name ips average deviation median 99th %
start_&_stop_processes-0.3.0-alpha 0.00925 1.80 min ±0.00% 1.80 min 1.80 min
Memory usage statistics:
Name Memory usage
start_&_stop_processes-0.3.0-alpha 15.95 GB
Future releases will address the memory allocations.
Hi, we are currently running on a single node and due to scaling challenges (good problem to have!) we are looking at ProcessHub to move to a multi-node setup.
Here is the meat of our code that uses DynamicSupevisor and Registry:
@doc """
Start a child process or return an existing one by the given key
- If the process is already exists for the key, it is returned
- If the process doesn't exist for the key, it will be created with config in `{mod, opts}`
"""
@spec start_child(
supervisor(),
term(),
{module(), keyword()}
) :: pid()
def start_child(supervisor, key, {mod, opts}) do
# the registry is actually the name of the supervisor
registry = supervisor
case lookup_child(registry, key) do
# Process already exists, just return it
pid when is_pid(pid) ->
pid
nil ->
{:ok, dynamic_supervisor} = Registry.meta(registry, :dynamic_supervisor)
via = {:via, Registry, {registry, key}}
# The child will need to be registered with a via tuple so that we
# have a stable process name to reference
opts = Keyword.merge(opts, name: via, restart: :temporary)
case DynamicSupervisor.start_child(dynamic_supervisor, {mod, opts}) do
{:ok, pid} -> pid
{:error, {:already_started, pid}} -> pid
end
end
end
If I wanted to swap to using ProcessHub, what things would I use to replace DynamicSupervisor and Registry?
Hi, something like this should work:
@spec start_child(
atom() | binary(),
{module(), function(), list()}
) :: pid() | {:error, term()}
def start_child(key, {mod, func, args}) do
hub_id = :my_hub
case ProcessHub.get_pid(hub_id, key) do
pid when is_pid(pid) ->
pid
nil ->
child_spec = %{
id: key,
start: {mod, func, args},
restart: :temporary
}
start_res =
ProcessHub.start_child(hub_id, child_spec, async_wait: true)
|> ProcessHub.await()
case start_res do
{:ok, res} ->
# Should be in this format: {"somekey", ["node1@127.0.0.1": #PID<0.225.0>]}
# Or get the pid from the registry
# `ProcessHub.get_pid(hub_id, key)`
elem(res, 1) |> List.first() |> elem(1)
{:error, msg} ->
{:error, msg}
end
end
end
I also changed few things:
hub_id if you would like it to be dynamic or you’re running multiple hubs on the same node.Supervisor.child_spec() before sending to the ProcessHub (maybe in the future release {mod, args} will also be supported).pid but may also return {:error, msg} because this operation may involve message passing between nodes and at this point you never know what may go wrong.Let me know if anythings unclear.
Have you seen Partisan (GitHub - lasp-lang/partisan: High-performance, high-scalability distributed computing for the BEAM. · GitHub) as an alternative mechanism for communication between nodes?
Shifters
This is interesting. In theory, it could work with ProcessHub out of the box if node monitoring is set up similarly. Something to perhaps try.
New version released 0.3.2-alpha 
## v0.3.2-alpha - 2025-04-16
Includes new feature and a breaking change. Minor improvements on documentations and other fixes.
### Breaking changes
- The process state handover has been unified for different types of migrations. Users who previously used HotSwap migration with process state handover and implemented their own custom callbacks instead of using the provided macro, will need to update their callback functions. See `ProcessHub.Strategy.Migration.HotSwap` for examples. This also removes the need to have a separate callback to handle `{:process_hub, :get_state, cid, from}` graceful shutdown migrations.
### Fixed
- Improved error handling. Single child start/stop operation error result no longer returns list.
- Fix: Prevent mix tasks from being included in production build. [https://github.com/alfetahe/process-hub/issues/10]
- Documentation typespecs and some comments.
- Minor code refactors.
### Added
- Adjusted `HookManager` documentation to allow `String.t()` as hook handler keys.
- Added new function `ProcessHub.promote_to_node/2` to handle updating the process registry after turning node node into distributed node. Useful when the node has been started as none distributed and later made into one by calling `Node.start/3` function.