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

[Pablo Platt]

Sounds perfect.
Thank you for the explanation.




________________________________
From: Ulf Wiger <ulf.wiger@REDACTED>
To: Pablo Platt <pablo.platt@REDACTED>
Cc: erlang-questions@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:

> 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




________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED