tangui

tangui

In the first 20 seconds after an http_cache_store_{disk,memory} starts, whenever another node shows up, a warm_me_up message is sent to the node that shows up, and the latter sends the n hottest stored HTTP responses.

Result will depend on your deployment type. If you’re doing rolling deployment then nodes still up will feed new nodes with HTTP responses, and the former nodes will benefit from the same mechanism once they are eventually restarted, receiving back the HTTP responses they sent to the first restarted nodes.

2
Post #11
dimitarvp

dimitarvp

This is a super useful explanation, thank you.

Last question: do the nodes sync caches after the warm_me_up message has been processed and the hottest requests cached?

0
Post #12
dimitarvp

dimitarvp

BTW I’d definitely put such a higher-level and very accessible explanation somewhere in the docs. Very often caching libraries / programs don’t make these things explicit and I usually end up skipping them for that exact reason.

1
Post #13
tangui

tangui

They constantly do that: each node caching a new HTTP response sends the {CacheKey, Timestamp} to all other nodes, which request the full HTTP response if they don’t know it.

Thing is that doc are scattered between different libs (http_cache, plug_http_cache and http_cache_store_disk for instance), but I’ve described overall capabilities in a blog post.

1
Post #14
dimitarvp

dimitarvp

Hm, here is where I question the usefulness of this. It’s a full HTTP request to warm up a cache that might take less time being fetched from the DB, so to me it gets a bit crazy at this point.

Admittedly I’ve rarely worked on systems that truly derived value from caches – still, almost never in my career were distributed caches useful. It was at least as efficient to have 3+ nodes each having a completely local RAM cache and hitting the DB and/or 3rd party APIs to populate those local caches. We even had metrics dashboards proving it.

This is why I am super curious about people using distributed caches: do you have metrics showing “time used to cache the thing” vs. “time to distribute the thing in caches” vs. “time to access the cached thing”?

0
Post #15
tangui

tangui

Just to make things clear: if the response is not cached on nodeA, it’ll hit the backend (DB, etc.) and not request the response from other nodes.

Cached HTTP responses sharing is done behind the scene, between the stores. HTTP response sharing is best effort, as everything else (no guarantee a cacheable response will be cached - see the blog post).

Now clustering is disabled by default, and indeed I’ve no feedback from it being used in prod so I don’t know for sure this response sharing is really useful. My experience in HTTP caching is with an very slow MongoDB/Elasticsearch BE and the more responses are cached, the better.

2
Post #16
D4no0

D4no0

I guess the best thing out of this is that you can warmup fast a node that was restarted/redeployed, can be quite useful if you are doing periodically small deploys (if the redeploys don’t happen at the same time on both nodes).

2
Post #17
cevado

cevado

weird, both documentations of Cachex and Nebulex explains exactly what to expect from their strategies to distribution. Cachex have a detailed explanation on what happens localy and what needs to go on the network. Nebulex include different strategies to accomodate different needs.

For exemple, an explanation of replicated cache from Nebulex, and it clearly explains that distribution happens on writes and that it replicates all values:
https://hexdocs.pm/nebulex/Nebulex.Adapters.Replicated.html

I’m not sure if you’re talking about caches in elixir or caches in general. :thinking:

2
Post #18
dimitarvp

dimitarvp

Oh I meant distributed caches in general, plus @tangui’s libraries. Thanks for the link, I’ll read through it.

0
Post #19
— All posts loaded —