[erlang-questions] gproc global will create a bootleneck in my app?
Mon Nov 15 21:15:08 CET 2010
Thank you for the explanation.
From: Ulf Wiger <ulf.wiger@REDACTED>
To: Pablo Platt <pablo.platt@REDACTED>
Sent: Mon, November 15, 2010 9:24:21 PM
Subject: Re: [erlang-questions] gproc global will create a bootleneck in my app?
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
> with gproc?
> Am I only limited by RAM?
Reasonable... when a process dies, the server will iterate through all its
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
RAM or (in 32-bit) addressable memory.
If processes come and go at a very high rate and register lots of names and
the gproc process is likely to become a bottleneck in your system. I don't know
this would become a problem. It's been used in systems with tens of thousand
registering a fair number of properties each at a rate of several hundred
Ulf Wiger, CTO, Erlang Solutions, Ltd.
erlang-questions (at) erlang.org mailing list.
To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
More information about the erlang-questions