Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation on how often to refresh nodes #30

Open
synth opened this issue Nov 8, 2017 · 2 comments
Open

Documentation on how often to refresh nodes #30

synth opened this issue Nov 8, 2017 · 2 comments

Comments

@synth
Copy link

synth commented Nov 8, 2017

The README states how you can refresh the client, but it does not state how often this should occur or by what means.

I couldn't find much documentation on how often or why Elasticache nodes might drop off or join. The only thing the AWS docs mention is that:

If a node fails, ElastiCache takes down that node and spins up a replacement. The replacement process takes a few minutes. During this time the metadata in all the nodes still shows the endpoint for the failed node, but any attempt to interact with the node will fail. Therefore, your logic should always include retry logic.
Reference

What are users of this gem expected to implement in terms of refreshing? I see in the Dalli-Elasticache docs that it refreshes upon app server restart. However, should we implement a refresh as a cron? Every 30minutes? Sample code would be most appreciated!

I've also posted a similar question on Stack overflow: https://stackoverflow.com/questions/47170376/how-to-refresh-clustered-redis-elasticache-nodes-in-a-rails-app
Thanks.

@Physium
Copy link

Physium commented Jan 13, 2021

So given that this was asked in 2017... was there any conclusion to this? Aside from how frequently is this being refreshed, in a typical rails app the config will be initialise on restart, how do I even call .refresh outside of production.rb?

@petergoldstein
Copy link
Collaborator

This is a good question and I plan to write up some documentation shortly. Some quick notes:

  1. In real ElastiCache clusters, node failures are infrequent - it is not uncommon for the set of nodes to stay constant for months if the cluster isn't scaled.
  2. Dalli will stop using a node for caching if it can't reach a node. It will distribute requests that would have previously gone to that node to other nodes in the cluster. So assuming that not all of the nodes in your cluster fail, then an individual node failure may degrade your caching performance but won't disable caching
  3. By default Dalli will attempt to reconnect to a node that has been previously marked unreachable after a period. So it should recover from transient node issues in which the set of nodes aren't changed.
  4. As of this writing (1/20/22), Dalli does not refresh the set of nodes after initialization of the Dalli::Client. That is, refreshing the Dalli::Elasticache set will have no impact on caching behavior for existing clients, including those configured for the Rails cache and session stores. Dalli requires enhancements to take advantage of node updates. Those may make it into Dalli 4.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants