4 ms·
This is interesting. I wrote a multithreaded actor implementation in Java without locks that can reach throughputs of 19 million assuming a batch size of 10 me
by samsquire 4y ago
This is interesting.
I wrote a multithreaded actor implementation in Java without locks that can reach throughputs of 19 million assuming a batch size of 10 messages at a time.
I am curious what a Rust message passing implementation throughputs would scale to given that it is a multithreaded problem and there's cost to synchronization. Synchronization is expensive.
https://github.com/samsquire/multiversion-concurrency-control https://github.com/samsquire/multiversion-concurrency-contro...
- throwaway894345 4y agoI have a vague understanding of actors and fault tolerance, but it's not clear to me if actors provide fault tolerance or if they just make concurrent programming less error prone? Would be happy for someone to stream-of-consciousness riff about how an Erlang-like fault tolerant approach to reliability compares with a more traditional approach in theory and in practice. E.g., if you have a component that is just erroring and restarting all the time, how does the operator know that something is wrong? Do you have special monitoring? Do you look for restarts in the logs? I guess maybe what I want to know is "how does operating an erlang-ish service compare to operating a traditional service?"
- samsquire 4y agoIf my actor crashes and the message hasn't been written to a write ahead log, the message would be lost since it's not easy to resume the processing of the message received without persisting it somewhere. I am not that familiar with Erlang's supervision hierarchies. You could do something similar to ActiveMQ and rebroadcast a message until it is acknowledged.