With several Phoenix apps clustered with
libcluster, it’s easy to make calls to remote nodes via
Say I have two different public-facing apps, and one needs to fetch data from the other to serve requests. Is it a reliable pattern to use
:erpc for this relationship? Are there known limitations or performance hits for concurrent requests over :erpc?
To be fair I’m not a big fan of doing rpc calls without a predefined contract, that can be enforced on both ends, it is just too easy to break the contract by accident.
IMO a monolith that has good separation of code will be times more easier to manage than those 2 separate services trying to communicate via rpc.
it is just too easy to break the contract by accident
The plan is to define a tested and documented API for use by
:erpc calls for exactly that reason. We have domain reasons for maintaining separate apps.
Architectural concerns aside, are there known limitations or performance hits for concurrent requests over :erpc?
Have you read the introduction paragraph for erpc? I guess this is an important pointer that is presented there: Erlang -- Processes
I’ve only used :rpc (or software that used rpc, erpc looks like a newer version) and I’ve never really hit limits on this. The situation was:
- Everything was in same dc(no wan)
- Everything was trusted.
- Less than 15 nodes connected (other network topologies exist that can connect more, but it was unnecessary as boxes wese beefy).
I don’t think there’s any reason not to use it? The alteratives aren’t that great either. Spending cpu serializing/deserializing json over http? After seeing 25% of the cpu going to parsing, deciding to go to a binary format like messagepack? As long as everything is trusted, single datacenter, and no reason to talk to non-BEAM languages, why not use the standard protocol? For instance, I never had any issues with riak clusters and I can’t think of any application that would be more chatty.
Then on modern hardware, I don’t think it will be very easy to hit the limits. Anyway, for further information:
Personally, I would be more concerned about security and the introduction of other languages than the scale in most situations.
@D4no0 I have read the introduction paragraph. I have also read the note about blocking signals, although I can’t say I totally understand it.
@tj0 there is a line in the introduction to
:erpc that says it “has better performance and scalability than the original rpc implementation” but with no implementation details. Based on the paper you linked, it appears even the original
:rpc would be scalable enough for our current needs. It’s good to know that
Node.spawn/4 is there if we do hit some of those bottlenecks.