Multi Server IO As A Last Resort
Modern computer systems are fast, really fast.
The speed of DDR5 (RAM) is around 5000 million transfers a second,
High-End Consumer CPUs have tens of cores or 3.2GHz clocks, sometimes both.
More and more software requires a internet connection, which isn’t necessarily bad,
But in a server setting, one should (probably) consider minimizing communication through the network.
(De)serialisation Is Expensive
Most of the time, when communicating over a network, a program continuously serializes and deserializes information. A binary User struct which lives in cache becomes UTF-8 JSON (assuming no zero-copy format is used).
Protobufs are a major improvement performance wise,
And while not completely eliminating the latency, capnproto enables an even greater performance improvement.
System Calls
Unless one uses kernel-bypass (like databases) or FPGAs (probably not), interacting with the network requires making a syscall, which causes a context switch, increasing overall latency.
A context switch also adds unpredictable latency (see RTOS).
Router Hops / Switches
A network packet does not travel in a linear manner, instead, it hops between routers (or switches, if it’s a single datacenter). The network packet’s route also is unpredictable, making latency unpredictable.
Packets Drop
There exists no guarantee a network packet will fully arrive / arrive at all. In fact, a packet “dropping” is relatively common (one of the reasons TCP exists),
Distributed Systems Are Hard
Distributed Systems Are Hard - Race Conditions Are Everywhere, Locks can cause deadlocks (which are hard to find, in most languages), Time needs to be synchronized (Lamport timestamps, NTP, PTP).
State Is Hard To Debug && Running Locally
Generally, the more state present, the harder it is to debug a function,
In addition, as a program has more isolated moving pieces, running it locally becomes a hassle (reducing productivity).
The article does not claim one approach is better than the other, pure opinion.
Contact:
ronfrie (at) proton (dot) me.
@nopipeline0 on twitter