<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><br>The one thing to watch for is that pg2 will take a global lock over all nodes in a mesh when a join/leave is done. This means that if you are doing lots of joins, and have a mesh of Erlang nodes, then there is a performance overhead. Not a massive one, but something to watch for.<div><br><div>> From: mallen@alertlogic.com<br>> To: erlang-questions@erlang.org<br>> Date: Wed, 11 Dec 2013 10:19:42 -0600<br>> Subject: [erlang-questions] pg2 scale limits<br>> <br>> What has been the experience of folks with the practical upper bound of<br>> process groups registered with the pg2 application?<br>> <br>> I have an application where I need to track 10000 or so process groups<br>> across a set of erlang nodes (2 R14B04 Erlang VMs running on top of 2<br>> Debian VMs to start.) Would that size of registry cause problems?<br>> <br>> I read <br>> http://christophermeiklejohn.com/erlang/2013/06/03/erlang-pg2-failure-seman<br>> tics.html and it was a great read - are there any other pitfalls about pg2<br>> that I should be aware of?<br>> <br>> I am planning to implement a "prototype" of this application using pg2 at<br>> reasonably low scale, but I am open to other implementation suggestions or<br>> applications (I looked at gproc too, but I'd rather stick with pg2 if<br>> possible because it comes "out of the box"...)<br>> <br>> Thanks.<br>> <br>> Mark<br>> <br>> _______________________________________________<br>> erlang-questions mailing list<br>> erlang-questions@erlang.org<br>> http://erlang.org/mailman/listinfo/erlang-questions<br></div></div> </div></body>
</html>