[erlang-questions] gproc global will create a bootleneck in my app?
Mon Nov 15 20:24:21 CET 2010
On 15 Nov 2010, at 15:11, Pablo Platt wrote:
> I'm using gproc to handle IM sessions on one node and it works great.
> I want to use it with gen_leader to extend to several nodes.
> Saving a global name will be slower because that leader has to coordinate
> Will it affect reads as well?
No, they are performed the same way for local and global lookups.
> If one gen_server is responsible for everything, does writing a global name
> might block all reads?
No, the lookup is done in the client process.
This constitutes a race condition, but process death is asynchronous anyway
so the race condition is inherent in the problem and cannot be removed.
> What is a reasonable number of unique names and non-unique properties I can save
> with gproc?
> Am I only limited by RAM?
Reasonable... when a process dies, the server will iterate through all its registered
names and properties and remove them. A huge number of registered items per
process will likely cause problems - perhaps even severe problems.
But as long as each process keeps within a reasonable limit (say, no more than a
hundred or so items), it should scale quite well, and you will be limited by available
RAM or (in 32-bit) addressable memory.
If processes come and go at a very high rate and register lots of names and properties,
the gproc process is likely to become a bottleneck in your system. I don't know when
this would become a problem. It's been used in systems with tens of thousand processes
registering a fair number of properties each at a rate of several hundred processes/sec.
Ulf Wiger, CTO, Erlang Solutions, Ltd.
More information about the erlang-questions