[erlang-questions] { ProcessName, NodeName } ! Message VS rpc:call/4 VS HTTP/1.1 across Erlang Nodes
Joshua Muzaaya
I have a setup in which two nodes are going to be
communicating a lot. On Node A, there are going to be thousands of
processes, which are meant to access services on Node B. There is going
to be a massive load of requests and responses across the two nodes. The
two Nodes, will be running on two different servers, each on its own
hardware server.
I have 3 Options: HTTP/1.1 , rpc:call/4 and Directly sending a
message to a registered gen_server on Node B. Let me explain each
option.
HTTP/1.1
Suppose that on Node A, i have an HTTP Client like Ibrowse, and on Node B, i have a web server like Yaws-1.95,
the web server being able to handle unlimited connections, the
operating system settings tweaked to allow yaws to handle all
connections. And then make my processes on Node A to communicate using
HTTP. In this case each method call, would mean a single HTTP request
and a reply. I believe there is an overhead here, but we are evaluating
options here. The erlang Built in mechanism called webtool, may be built for this kind of purpose.
rpc:call/4
I could simply make direct rpc calls
from Node A to Node B. I am not very sure how the underlying rpc
mechanism works , but i think that when two erlang nodes connect via net_adm:ping/1,
the created connection is not closed but all rpc calls use this pipe to
transmit requests and pass responses. Please correct me on this one.
Sending a Message from Node A to Node B
I could make my processes on Node A to just send message to a
registered process, or a group of processes on Node B. This too seems a
clean option.
Q1. Which of the above options would you recommend and why, for
an application in which two erlang nodes are going to have enormous
communications between them all the time. Imagine a messaging system, in
which two erlang nodes are the routers :) ?
Q2. Which of
the above methods is cleaner, less problematic and is more fault
tolerant (i mean here that, the method should NOT have single point of
failure, that could lead to all processes on Node A blind) ?
Q3. The mechanism of your choice: how would you make it even more fault tolerant, or redundant?
Assumptions:
The Nodes are always alive and will never go down, the network
connection between the nodes will always be available and non-congested
(dedicated to the two nodes only) , the operating system have allocated
maximum resources to these two nodes.
Thank you for your evaluations
Loïc Hoguin
etc. if you are going to need them to communicate a lot. Plus your
setting makes a lot of sense for distribution.
Apart from that, benchmark! :)
On 11/09/2012 06:20 AM, Joshua Muzaaya wrote:
>
> I have a setup in which two nodes are going to be communicating a lot.
> On Node A, there are going to be thousands of processes, which are meant
> to access services on Node B. There is going to be a massive load of
> requests and responses across the two nodes. The two Nodes, will be
> running on two different servers, each on its own hardware server.
>
> I have 3 Options: HTTP/1.1 , rpc:call/4 and Directly sending a message
> to a registered gen_server on Node B. Let me explain each option.
>
>
> Suppose that on Node A, i have an HTTP Client like |Ibrowse|, and on
> Node B, i have a web server like |Yaws-1.95|, the web server being able
> to allow yaws to handle all connections. And then make my processes on
> Node A to communicate using HTTP. In this case each method call, would
> mean a single HTTP request and a reply. I believe there is an overhead
> here, but we are evaluating options here. The erlang Built in mechanism
>
> *rpc:call/4*
> I could simply make direct rpc calls from Node A to Node B. I am not
> very sure how the underlying rpc mechanism works , but i think that when
> responses. Please correct me on this one.
>
> I could make my processes on Node A to just send message to a registered
> process, or a group of processes on Node B. This too seems a clean option.
>
> communications between them all the time. Imagine a messaging system, in
> which two erlang nodes are the routers :) ?
>
> point of failure, that could lead to all processes on Node A blind) ?
>
> fault tolerant, or redundant?
>
> *Assumptions: * The Nodes are always alive and will never go down, the
> non-congested (dedicated to the two nodes only) , the operating system
> have allocated maximum resources to these two nodes.
>
> Thank you for your evaluations
>
>
>
>
>
>
>
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Konstantin Tcepliaev
,
Joshua Muzaaya
*Muzaaya Joshua
Systems Engineer
+256774115170*
*"Through it all, i have learned to trust in Jesus. To depend upon His Word"
*
Chandru
With HTTP, you can get that by letting your HTTP client do the throttling. That said, it does come with a processing overhead.
cheers
Chandru