Yeah, you are absolutely right 
I thought it was weird… 
alexcastano
alexcastano
I found this benchmark which answers my own question, very interesting:
https://github.com/savonarola/redis_vs_simple_erlang_benchmark
2
jordiee
I do not think this is a good benchmark at all. It has all ets writes going through a single genserver process that basically becomes the bottleneck. If it did not send everything through a genserver I would be much more interested.
0
alexcastano
That’s exactly the point 
A “Singleton ETS” would be a GenServer for a whole cluster where data is saved only once. It is good because it is memory efficient and much simpler to update. It is bad because it is less fault tolerant and slower. This benchmark tells us how slow it is. I think, for a lot of people, it will be fast enough.
0
michalmuskala
The problem is that this ignores some other things like the fact that you copy things twice - once from ETS and once between GenServer and the target process. Probably a better approach to testing things when running single-threaded would be to use ETS how you would normally use it, but start the Erlang VM with just one scheduler using --erl "+S 1:1".
0
alexcastano
@michalmuskala Is possible to retrieve data from a remote node ETS avoiding the copy duplication that you mention?
I understand that ETS is usually used for local node data, but I wanted to avoid the complexity of writing in multiple nodes and any incoherences that could happen in the process.
0
pggalaviz
Sorry for the late reply.
I think what @jordiee tried to say is that in the benckmark, all ETS calls are going through the GenServer’s callbacks, effectively generating a bottleneck.
If instead of calling the GenServer you just call the ETS directly (eg. RPC call to the node who owns the ETS) you’ll get better performance, the GenServer will only be used to start and own the ETS.
I wrote a blog post about a toy distributed rate limiter in Elixir that better explains it: Simple distributed rate limiter with Elixir · Pedro G. Galaviz
2