ETS entry limit, to use as a cache server

Question

My idea is to use ETS as a temporary cache for my GenServer state.

For example when I restart my application, the GenServer state should be transported to ETS and when the application starts again, the GenServer should be able to get the state from there.

I would like to keep it simple, so all the state (a Map) from the GenServer should take a single entry. Is there a limit for entry-sizes?

Another approach would be, to simply create a file, and load it again, when needed. Maybe this is even better/simpler, but I am not sure :)

In case of an ETS table, the App could start on a completely other host, and connect to the Cache Node (ETS).

ETS table is linked with the creator process, so when your gen_server crashes, its ETS tables are removed (unless specified heir). You could use DETS or Mnesia. — Tomasz Maciejewski
@TomaszMaciejewski you can also have a public ETS, so no need for a heir. Also, he is talking about that ETS table residing on a different node so that issue would not really arise in the way you are mentioning. Your observation is correct though that ultimately he would be recreating Mnesia in some form or the other. — Kevin Johnson
Since your use case seems very foreseeable, I think that using a file would be the simplest solution: save the state: file:write_file(FileName,io_lib:format("~tp.~n", [State]))., restore the state: {ok,[State]} = file:consult(FileName)., if you want you can add some code to check it has worked properly. — Pascal
@Pascal the file solution seems to be the simplest one, I'll give it a try.kiss :) — webdeb
if you use a different node, and create an interface using the owner process, any other node will have access to the data in the ETS. I don't see any problems. You'd have to limit the access to the ETS through an API, otherwise you'd have problems if two nodes try to access or change the data at the same time. ETS don't have transactions. — Roman Rabinovich

Kevin Johnson Kevin Johnson · Accepted Answer · 2018-02-04T18:51:23

This can most certainly be done in a wide variety of ways. You could have a separate store, like Mnesia(which is ETS under the hood), Redis or a plain database. In the latter two cases, you would need to cast your Genserver state to a string and back doing: :erlang.term_to_binary and :erlang.binary_to_term respectively.

In the case that you are dealing with multiple GenServer processes that need to be cached in this way, e.g. every GenServer represents a unique customer cart for instance, then that unique identifier can be utilized as the key under which to store the state which can then later on be retrieved. This is particularly useful when you are running your shopping application on multiple nodes behind a load balancer, and every new request on part of a customer can get 'round robin'-ned around to any random node.

When the request comes in:

fetch the unique identifier belonging to that customer in one way or the other,
fetch the stored contents from wherever that may be(Mnesia/Redis/...),
spawn up a new GenServer process initialized with that stored contents,
do the various operations required for that request,
store the latest modified GenServer shopping cart into Redis/Mnesia/wherever,
tear down the GenServer and
respond to the request with whatever data is required.

Based on the Benchmarks I have done of ETS vs Redis on my local, it is no surprise that ETS is the more performant way to go, but ElastiCache is an awesome alternative if you are not in the mood to bother spinning up a dedicated Mnesia store.

In the case it pertains to a specific GenServer that needs to run, then you are most likely looking at failover as opposed to managing individual user requests.

In such a case, you could consider using something like: https://hexdocs.pm/elixir/GenServer.html#c:terminate/2 to have the state first persisted to some store and in your init make the GenServer first look in that store and reuse the cache accordingly.

The complicated matter here is in the scenario where you have multiple applications running, which key will you utilize in order to have the crashed application reinitialize the GenServer with the correct state?

There are several open ended questions over here that revolve around your exact use case, but what has been presented so far should give you a fair idea as to when it makes sense to utilize this caching solution and how to start implementing it.

ETS entry limit, to use as a cache server

1 Answers