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

Adding fetch_multi to Cache Strategy #827

Open
joaomdmoura opened this issue Mar 6, 2015 · 8 comments
Open

Adding fetch_multi to Cache Strategy #827

joaomdmoura opened this issue Mar 6, 2015 · 8 comments

Comments

@joaomdmoura
Copy link
Member

As pointed out by @thibaudgg on my last PR #810 (Adding Fragment Cache to AMS), fetch_multi would be a great optimisation to the new cache implementation (#693).

One feature of the new implementation is the individual cache strategy. It enables your application to re-use the cache in different responses.

Ex. It can re-use an object cached from a index method response, on a show method response. The opposite is also true.

AMS will also retrieve this cached objects individually, and that's when fetch_multi comes in. It improves performance by retrieving multiple cache keys for a collection in a single go.

Despite of a simple improvement, it isn't easy. It will change how the Adapter fetches cache and how it integrates with FragmentCache

I'm planning to work on this, but would like to hear some thoughts :)

@thibaudgg
Copy link

Great news, thanks @joaomdmoura!
I'm not familiar with the implementation, but IMHO adding fetch_multi seems really mandatory for production.
It would works and reuse the object cached for associations as well right?

@joaomdmoura
Copy link
Member Author

@thibaudgg I don't think it's mandatory (we are already conducting some production tests) but yeah, it's definitively a great optimisation! Really useful!
In this case it wouldn't be necessary in cached associations. The associations doesn't generate an individual cache for the associated object. It's cached along the original requested object.

@thibaudgg
Copy link

@joaomdmoura you're right "mandatory" is too strong, but definitely great to have.
My point with associations is to have each object cached separately, so for example if you load & cache a post with comments and you want to load just a comment after it should already be cached.
I guess that @kurko's comment goes in that direction.

@joaomdmoura
Copy link
Member Author

Yeah @thibaudgg we discussed it yesterday and we'll move forward with this strategy! 😄 I'm not sure if fetch_multi will be used to associations yet, but they will be cache separately

@thibaudgg
Copy link

Great, keep up the good work!

@bf4
Copy link
Member

bf4 commented Sep 17, 2015

The related thoughtbot article is pretty good, even though for 0.8 https://robots.thoughtbot.com/fast-json-apis-in-rails-with-key-based-caches-and

@philipgiuliani
Copy link

Already any updates on this? I noticed that most of the time my controller spends to talk with redis for fetching the records. Would be a great improvement!

@bf4
Copy link
Member

bf4 commented Nov 3, 2015

Wanna help?

B mobile phone

On Nov 3, 2015, at 2:12 AM, Philip Giuliani [email protected] wrote:

Already any updates on this? I noticed that most of the time my controller spends to talk with redis for fetching the records. Would be a great improvement!


Reply to this email directly or view it on GitHub.

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

No branches or pull requests

5 participants