[erlang-questions] Distributed Process Registry

[Michael Truog]

On 02/09/2015 01:32 AM, Paul Oliver wrote:
> Hi Roberto,
>
> In my experience cpg struggles with a high volume of joins/leaves.  By default it uses a single gen_server as part of all such calls (the default scope) and in my production system this ended up being a bottleneck.  A potential workaround might be to create a bunch of scopes and hash over them.
Yes, using more than the single cpg scope would utilize more than the single Erlang process to avoid it becoming a bottleneck.  It also helps to use cached cpg data for the process lookups to avoid adding extra load to the cpg scope Erlang process by using the cpg_data module (after receiving the cpg data with cpg_data:get_groups/2 function) which is equivalent to what happens for a lazy destination refresh in CloudI when sending a service request.
>
> Cheers,
> Paul.
>
> On Sun Feb 08 2015 at 11:07:52 PM Roberto Ostinelli <roberto.ostinelli@REDACTED <mailto:roberto.ostinelli@REDACTED>> wrote:
>
>     Hi Michael,
>     Do you know what the impact of this is when you add/remove keys often? I'm imagining a lot of communication (async) happening between nodes.
>
>     I'm actually very ok with the AP portion of the CAP theorem (that pg2 seems to offer) in contrast with the CA (of global/gproc).
>
>     Just wandering if there are studies and impact on performance. As said, I have 3 nodes with a total of 500k pids that need registration
>
>     Thanks,
>     r.
>
>
>
>     > On 08/feb/2015, at 22:10, Michael Truog <mjtruog@REDACTED <mailto:mjtruog@REDACTED>> wrote:
>     >
>     > The main reason is that you avoid the need to resolve state conflicts when global state gets merged after a netsplit.  With pg2 and cpg, all the state relevant to the local node is stored locally and remote state gets merged as nodes are added.  When a node dies, its pids are removed, as expected, but there is no need for centralized global state.
>     _______________________________________________
>     erlang-questions mailing list
>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>     http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150209/f86fd095/attachment.htm>