<div dir="ltr">Here is an alternative suggestion based on my experience of implementing our own rpc mechanism precisely because of the problems you mention. I alluded briefly to this during my CodeMesh presentation last year as well (<a href="http://www.codemesh.io/static/upload/media/14478899074266codemesh2015.pdf">http://www.codemesh.io/static/upload/media/14478899074266codemesh2015.pdf</a>) - slides 30-33<div><br></div><div>The idea is to remove the use of rex completely, and extend the RPC mechanism with these features.</div><div><br></div><div>* Named RPC endpoints which allow connections to multiple nodes</div><div>So supposed you have three erlang nodes which offer the same service, let's call them db@host_1, db@host_2, db@host_3, it would be nice to have a single RPC endpoint called DB, which sets up and maintains connections to all 3 nodes, and to be able to invoke it as. This would also give you your application specific RPC connections.</div><div><br></div><div>rpc:call('DB', some_module, some_function, [args,...])</div><div> <br></div><div>* Load balancing between these connections using different load balancing strategies</div><div><br></div><div>* Seamless failover so that clients aren't aware that one of the nodes is down (if you really wanted to know, then you could use erlang:monitor_node/2,3)</div><div><br></div><div>* Ability to use multiple TCP connections behind the same endpoint (and this could be easily extended to use TLS instead)</div><div><br></div><div>I had implemented all this at my previous place of work and we had a lot of success with it. This was done as a separate application obviously, but it would be good to finally get rid of rex and its associated problems.</div><div><br></div><div>cheers,</div><div>Chandru</div><div><br></div><div><br></div><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 11 February 2016 at 21:04, José Valim <span dir="ltr"><<a href="mailto:jose.valim@plataformatec.com.br" target="_blank">jose.valim@plataformatec.com.br</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello everyone,<div><br></div><div>I was reading the publication "<a href="http://www.dcs.gla.ac.uk/~amirg/publications/DE-Bench.pdf" target="_blank">Investigating the Scalability Limits of Distributed Erlang</a>" and one of the conclusions is:</div><div><br></div><div><i>> We observed that distributed Erlang scales linearly up to 150 nodes when no global command is made. Our results reveal that the latency of rpc calls rises as cluster size grows. This shows that spawn scales much better than rpc and using spawn instead of rpc in the sake of scalability is advised. </i><br clear="all"><div><div><div dir="ltr"><div><div><br></div><div>The reason why is highlighted in a previous section:</div><div><br></div><div><i>> To find out why rpc’s latency increases as the cluster size grows, we need to know more about rpc. (...) There is a generic server process (gen server) on each Erlang node which is named rex. This process is responsible for receiving and handling all rpc requests that come to an Erlang node. After handling the request, generated results will be returned to the source node. In addition to user applications, rpc is also used by many built-in OTP modules, and so it can be overloaded as a shared service.</i><br></div><div><br></div><div>In other words, the more applications we have relying on rpc, the more likely rpc will become a bottleneck and increase latency. I believe we have three options here:</div><div><br></div><div>1. Promote spawn over rpc, as the paper conclusion did (i.e. mention spawn in the rpc docs and so on)</div><div>2. Leave things as is</div><div>3. Allow "more scalable" usage of rpc by supporting application specific rpc instances</div><div><br></div><div>In particular, my proposal for 3 is to allow developers to spawn their own rpc processes. In other words, we can expose:</div><div><br></div></div></div></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div><div dir="ltr"><div><div>rpc:start_link(my_app_rpc) %% start your own rpc</div></div></div></div></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div><div dir="ltr"><div>rpc:call({my_app_rpc, nodename}, foo, bar, [1, 2, 3]) %% invoke your own rpc at the given node</div></div></div></div></div></blockquote><div><div><div><div dir="ltr"><div><div><br></div><div>This is a very simple solution that moves the bottleneck away from rpc's rex process since developers can place their own rpc processes in their application's tree. The code changes required to support this feature are also minimal and are almost all at the API level, i.e. support a tuple were today a node is expected or allow the name as argument, mimicking the same API provided by gen_server that rpc relies on. We won't change implementation details. Finally, I believe it will provide a more predictable usage of rpc.</div><div><br></div><div>Feedback is appreciated!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div><span style="font-size:13px"><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b>José Valim</b></span></div><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><div><span style="font-family:verdana,sans-serif;font-size:x-small"><a href="http://www.plataformatec.com.br/" style="color:rgb(42,93,176)" target="_blank">www.plataformatec.com.br</a></span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Skype: jv.ptec</span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Founder and Director of R&D</span></div></span></div></span></div></font></span></div></div></div></div>
</div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>