lalo2302
Agent vs Registry
Hi guys!
I am facing a problem where I need to spawn multiple processes, and I have to keep a counter about every process. The counter needs to be indepent and accesing it should not interfiere with the process performance.
Saying this, I am exploring the options of Agent vs Registry.
If I use the Agent module, I would register an Agent for each process :via a Registry.
But how should this be different from only using a Registry, with the register function and the counter as a value.
Isn’t a registry the same as an Agent in that case?
Later today I’ll benchmark it, but wanted to know what do you think. I’ll post my results below.
Have a nice day!
Marked As Solved
CptnKirk
I would also recommend looking into GenStage for this. You don’t have a tell/ask problem. You want to limit the rate at which you get told something to the amount of capacity you have to process those tells.
This is what GenStage does. You advertise that you’re able to handle some number of events, and then you eventually get at most that number. Once you decide you can handle more events, you advertise that you’re able to handle more. This is all done more or less transparently for you by GenStage.
As you’ve already discovered, architecting a solution to your problem with Process.info doesn’t work well.
Consider using GenStage to solve your rate problem. Then within GenStage, delegate to a module that is focused on data processing. This way you’ve separated your business problem from your rate problem. And you can test your business module easily.
Agents and Registries aren’t required here. Although you’re free to register your GenStage processes with a Registry and/or hold state within an Agent. Up to you, they are different tools for different problems.
Edit: You may also want to look at Flow. Flow helps to provide a higher level data flow/processing abstraction, so you don’t need to worry about implementing a GenStage. If your workers are mapping or reducing something, then Flow could be a great fit.
Also Liked
josevalim
You are already making a big assumption that you will need processes. Could you please tell us about the problem you want to solve in general and why did you arrive to the conclusion that you need processes?
Why are you keeping count of how much work a process has done? Why not have a single process that does a single work and then dies?
peerreynders
I think the answer to your problem is another process which is only responsible for the counter.
- The process doing the work notifies its counter process when the count is updated
- Other processes call the counter process to obtain the current state.
Alternately it may make more sense for the counter process to be subscription based - otherwise you are building an “ask architecture” rather than a “tell architecture” (Tell, Don’t Ask).
Personally Agents make me queasy because anybody can mess with their internal state which has the smell of “global mutability”.
Registry pubsub may be an interesting option - though I haven’t looked at it in detail (if I’m reading the source correctly, dispatch/4 will run in the calling process rather than queuing the function to be executed later within the registry’s process, so I would classify this approach as “interfering with process performance”).
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #javascript
- #code-sync
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








