New to Elixir is this App architecture feasible?

Hello everyone, I am new to Elixir and after reading around the internet regarding the (lack of) performance of Elixir/Erlang message passing (no offense intended), using the Elixir docs (very high quality imo!) I came up with the following “test case” architecture to see if Elixir is a good fit for the type of problems I solve:

http://192.210.237.111/Benchmark_ETS_system.png

Before I either learn enough Elixir to do this myself, or pay someone else to build this benchmark for me. I wanted to post here and ask is this completely wrong/infeasible? Has this been done before, if so where can I find the results? Should I stick to C++ backends if I care about milliseconds?

Thanks in advance

Should I stick to C++ backends if I care about milliseconds?

Yes, you’re not going to see the kind of ~throughput~ latency you might be used to.

If you care about having a responsive system under high load then elixir/erlang will shine. (There are plenty of other reasons too, but I won’t enumerate them because people far more eloquent than I already have)

1 Like

Is that true? Millisecond responses are reasonable in elixir land, and the beam is optimized for throughput, not latency (ms latency is no big deal), but generally your bottleneck is going to be network in a distributed system like this. Only problem is that the diagram doesn’t show an end-to-end client story, so how can we know what the user latency should be in the first place?

Unless you are doing something like a high-frequency trading system, or an automated manufacturing architecture where 1-5ms latency might mean broken materials (or machines) then Elixir will serve you just fine.

But to be able to answer properly you should tell us: how much load do you expect? Is the latency critical and how much (with what timing tolerance)? What’s your general intended use-case?

With practice during the last ~3.8 years I found that people very often underestimate Elixir, to their future peril. The runtime can do a lot. Not to mention that the diagram you so nicely provided would be months of work with many other runtimes. With the BEAM, that diagram is possible after 1-2 weeks of work prototyping the OTP app(s) / supervisors / workers structure – then the runtime just makes it happen.


One example for bad tech choice when near-realtime is required are the people who regularly pick Golang only to be bitten hard by its growing GC pauses as the load and memory usage grows; Golang’s GC prefers to slack off and delay work for the future which works perfectly in a lot of apps because they don’t have constant memory pressure. But the people who are after near-realtime systems usually are in for a rough wakeup call because the GC pauses just grow and grow until your system starts missing messages and some responses start taking seconds to finish.

Such people would have been better off picking D or Rust and just get some elbow grease.


So, depending on what you’re after, Elixir might be perfect (because it allows for your architecture and will take you there very quickly in terms of dev iterations) but it could also be awful (if you are after 1 microsecond latency or less – mind you, it could provide that but it doesn’t guarantee it).


EDIT: Just read the diagram in more details. You are saying you are after 50ms or less. This is very doable in the BEAM but it will depend a lot on the I/O stack and memory controller of your hardware. Using GenStage / Flow / Broadway you can be applying back-pressure to the producers of data and tune your system for maximum throughput while still having <50ms response time. That however would require you to invest in telemetry in your code – and a backing time-series database so you could make your own statistics.

2 Likes