[erlang-questions] gproc global will create a bootleneck in my app?

[Ulf Wiger]

On 15 Nov 2010, at 15:11, Pablo Platt wrote:

> Hi,
> 
> 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 
> uniqueness.
> 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.

BR,
Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com