Options for persistent Pow session cache that are cost effective?

Phoenix Forum Questions / Help
, ,
1

I’m currently looking at backend options for storing session cache data for Pow. I have a single server running on Gigalixir and I’m trying to keep it that way (for now) to keep costs low.

Looking through the Pow documentation, you can setup Mnesia - which is awesome. But in the case of a single node, it requires persistent disk storage for the cache to survive a pod/docker container replacement.

In the case of Gigalixir, file storage is ephemeral - so that means I have the following options:

  1. Switch my deployment method to hot upgrades to prevent the container from being destroyed
  2. Add a second node - then the cache can propagate itself as nodes go down and come back up
  3. Implement the cache using Redis and find a 3rd party service

At this point, it looks like point 1) is the most cost effective solution.

Point 2) would take me out of the free tier and increase cost. Also, I’m not familiar with the mechanics of 1 node coming up and the next node going down. Is there enough time to copy the session cache - particularly if you only have 2 nodes? Does that mean I’d need 3 nodes at minimum?

I looked into point 3) with Google Memorystore - that introduces a cost of $35 per month. I’m not familiar with the cost of other services. A 3rd party solution may have other trade offs to consider - like network traffic costs (I’m currently in Google Cloud) and speed.

Is there anything else I should be thinking about?

2

What kind of information are you trying to persist?

3

An alternative is to use the DB for cache store. The cache stores are built around key-value store with TTL so it’s not really the right tool for the job, but it’s worth looking into if your first option doesn’t work well enough.

The Redis store cache backend guide is short enough to give you a good idea how the cache should work: https://hexdocs.pm/pow/redis_cache_store_backend.html#content

I would probably set it up as a GenServer similar to the ETS cache: https://github.com/danschultzer/pow/blob/v1.0.13/lib/pow/store/backend/ets_cache.ex

Just remember to handle TTL so expired entries are cleared out. In the ETS and Mnesia cache stores invalidator callbacks are used, and if you want to do this you have to make sure that the invalidators are initiated again on restart (same as how the Mnesia cache handles it).

However, it’ll likely be easier if you just deal with it by using the relational structure in SQL, and add the namespace, key, value and expiration as individual columns. Maybe user id should be a column too. Then you can periodically flush the table for expired entries instead.

1 Like
4

Hello!

It’s a user/session store. I haven’t looked into the data that Pow’s managing, but I’m assuming it stores the fields of the user table plus some meta data.

5

Is the point to avoid querying the database? Are you running into concrete performance issues or is caching this data speculative?

1 Like
6

Oh no, performance isn’t a concern yet (I have 1 regular user!). The main issue I’m facing right now is that I don’t want users kicked off the website just because I push an update. Since Pow utilises a session cache, I’m just trying to find the best way to persist the cache (without incurring cost).

@danschultzer, awesome information (as usual). I might have a stab at implementing a db cache and see how it goes. In the interim, I’ll push out hot upgrades

1 Like
7

It’s a nice advantage, but it’s mostly about ephemeral storage. Often the DB isn’t the right place for that.

Yeah, it usually consists of a randomly generated key and a map with user struct and some metadata. PowPersistentSession and PowResetPassword also uses the backend store.

8

Ephemeral storage of what? If it’s ephemeral, why does it need to be also persisted between reboots?

9

Because a session or reset token may have been created just before deploy/reboot.

10

If it’s an actual cache then it doesn’t really matter, the canonical state is either the database or the user token (if doing something like JWT) and then the cache can be rebuilt as requests come in. If the “cache” is actually the canonical store then that’s an issue, and neither redis nor mnesia nor hot loading are particularly durable solutions. If the cache is the canonical store, it is not ephemeral.

3 Likes
11

I get what you’re saying, the credentials store or reset token store is the source of truth and can’t be ephemeral. Behind the store layers (like credentials store that contains sessions), I use a cache layer that handles short lived key-value items. Both layers can be replaced with whatever you need.

I have found it most practical to treat what is stored in the cache largely as ephemeral data, that can be flushed without any major downside. E.g. a session shouldn’t exist after the user leaves the site. By default ETS is used for this layer, but since that’s inconvenient in a production environment, Mnesia or Redis is recommended so the tokens can survive between restarts.

This data shouldn’t be backed up, the data persisted to the disk is temporary, and if a node connects to a cluster, any local cache data it may have in memory (or on disk) has to be overridden by the cache in the cluster. It isn’t meant to be durable. The user struct with the credentials used for authentication, is the only thing that has to be persisted.

There may be a better term for it, but I hope this clarifies what the data is in the cache backend in Pow.

3 Likes
12

How would I start doing this? I also want to maintain sessions after deploys

13

As mentioned above, you can work it out from the Redis or ETSCache module. But is there a reason for not using Mnesia?

14

I tried using Mnesia and a permanent disk but couldn’t change Mnesia.nonode@nohost folder where data is stored to the folder I needed

15

You can change it by using this config setting:

config :mnesia, dir: '/path/to/dir'

Just make sure the directory is accessible.

16

I created a folder /mnesia in my repo and give it chmod 777

this is my config:

config :mnesia,
dir: '/mnesia'


config :pelable, :pow,
  user: Pelable.Users.User,
  repo: Pelable.Repo,
  web_module: PelableWeb,
  cache_store_backend: Pow.Store.Backend.MnesiaCache,
  extensions: [PowResetPassword, PowEmailConfirmation, PowPersistentSession],
  controller_callbacks: Pow.Extension.Phoenix.ControllerCallbacks,
  mailer_backend: PelableWeb.PowMailer,
  web_mailer_module: PelableWeb,
  routes_backend: PelableWeb.Pow.Routes

but when I start the server: mix phx.server

I get the following:

** (Mix) Could not start application pelable: Pelable.Application.start(:normal, []) returned an error: shutdown: failed to start child: Pow.Store.Backend.MnesiaCache
    ** (EXIT) an exception was raised:
        ** (CaseClauseError) no case clause matching: {:aborted, {'Cannot create Mnesia dir', '/mnesia', :eacces}}
            (pow) lib/pow/store/backend/mnesia_cache.ex:346: Pow.Store.Backend.MnesiaCache.change_table_copy_type/1
            (pow) lib/pow/store/backend/mnesia_cache.ex:294: Pow.Store.Backend.MnesiaCache.init_cluster/1
            (pow) lib/pow/store/backend/mnesia_cache.ex:125: Pow.Store.Backend.MnesiaCache.init/1
            (stdlib) gen_server.erl:374: :gen_server.init_it/2
            (stdlib) gen_server.erl:342: :gen_server.init_it/6
            (stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
17

Did you mean it to be relative to CWD? Then you should use ./mnesia instead. The error means that the /mnesia directory is not accessible. If it is indeed in root, then you have to ensure that the app has access to it.

18

One thing I’ve done in the past is setup a free heroku Redis and then point to it from another app. :grimacing: it is free and easy to setup

1 Like
19

You can use pow with just session cookies. Then you don’t need a store for sessions at all. The main README even mentions how to do it.

I’m using a slightly modified version of this in production. It is worth noting that password resets also use the store, so if you’re using that, you’ll have to figure out something for that.

2 Likes
20

oh I didn’t know, that seems like the most straightforward of doing it

yes that’s what I meant thank you

That’s a good option as well as I wouldn’t have to pay :smile: