[erlang-questions] Structure of a *scalable* application?
Chris Pacejo
colanderman@REDACTED
Fri Aug 22 19:34:22 CEST 2014
On Fri, Aug 22, 2014 at 12:24 PM, Michael Loftis <mloftis@REDACTED> wrote:
> Those are all design decisions, none of which will affect your scaling much IMO,
Yes that I realize; I just wonder if there is one "accepted" way.
> but one of your assumptions, only one worker per node, your
> "scaling" would suck,
Sorry, I mean in the context of CPU-boundedness. I want to keep the
example simple.
By "worker", it may be more general to say "agent within the node
which can accept and distribute work within the node".
> Most erlang applications are designed to run an instance per node of the
> application module, they then RPC to other instances as necessary (see
> mnesia). I can't think of any offhand where a single application
> instance runs across multiple nodes but I'm sure it exists.
OK, this makes sense.
> Further as to 3) the erlang distribution protocol runs over TCP. It
> has it's own scaling limitations as some have found out - f/ex if
> you're pushing many megabyte files at a high rate, it might be better
> to have your own RPC mechanism to transfer those rather than sending
> them over erlang distribution directly - the distribution protocol
> comes down to a single thread on a single socket and can become a
> bottleneck for inter-node communications.
Yes this I'm aware of. The system I'm building is moreso "small
number of nodes which are CPU or I/O-bandwidth-bound", not "large
number of nodes" nor "I/O-latency bound".
> Really though the best advice is to get it right first, then get it
> fast. Early optimization often isn't nearly as much of a win as
> people think.
Yes I know. I just want to make sure I structure my application in
such a way that when it comes time to scale, I don't have to refactor
everything.
Thanks!
More information about the erlang-questions
mailing list