[erlang-questions] global module limits

[James Churchman]

Download gproc, find some suitable hardware for you (does ec2 fit? ) benchmark it  on 1 2 4 & 8 connected nodes.. and write a blog post to share all the finding :-)
On 7 Feb 2011, at 17:07, Paolo Negri wrote:

> Dear list
> 
> I've been reading various opinions about the global module and I'd
> like some light to be shed on its limits and their underlying reasons.
> Particularly I'd like to understand what are its limit relative to
> register a big number of processes.
> 
> How do the following factors affect the global module performance
> 
> - number of registered processes at a given time, is this a problem if
> the registered processes are in the order of 1K 10K or 100K
> - registration rate, what if I register 10 100 or 1000 processes per seconds
> - lookup rate, this is how often the global name registry is queried
> - de-registration rate, symmetrical to the question above, 10 100 or
> 1000 registered processes terminate per second
> - overall number of registered processes over time: assuming that in a
> given second processes are registered at the same rate at which old
> registered processes terminate, the number of currently registered
> processes is constant (say 10K) but overtime I might have registered
> 1000K different process names, does the "register history" get cleaned
> or it'll stick around in the global environment?
> - cluster replication overhead, how does the number of nodes in a
> system affect the performance of the global registration facility?
> 
> On a side note I would be very interested in people willing to share
> experiences in using in production the gproc[1] project using it's
> global facility to handle in the region of 100K to 1000K processes.
> 
> [1] https://github.com/esl/gproc
> 
> Thanks in advance for your answers.
> 
> Paolo
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>