AMS: Caching

[Raik Osiablo]

Hey dudes,

I'm a happy user of AMS for some time and would like to contribute some stuff by myself now.

I noticed that the caching design/concept/implemention for v0.9 is still missing (at least I couldn't find anything about the planned reimplementation anywhere). Is there a document somewhere where the actual status is written down? Would be really nice to have a starting point... I'd really like to help here because proper caching is imho a crucial part for any scalable app.

Thanks in advance.

Raik

[Matthijs Langenberg]

With Jbuilder (https://github.com/rails/jbuilder) it is really easy to use Russian Doll Caching for JSON APIs. 

It works exactly the same as ERB templates.

Why is caching removed from AMS? And why is there no proposed solution yet for 0.9.0? I understand the current_user state would need some thinking, but otherwise it is just merging hashes, right?

Rewrite to Jbuilder to improve up API response time?

[Steve Klabnik]

Caching was removed because we weren't happy with how it's worked, and
because 0.9 was a total re-write.

There's no proposed solution because nobody has proposed a solution.
It's really that simple. I feel like this sentence sounds like I'm
being a jerk, but I'm not trying to be. Nobody has done the work, so
the feature isn't there.

[Matthijs Langenberg]

That makes a lot of sense. No, you do not sound like a jerk at all.

I would be happy to submit a proposal, but I am afraid that because I do not know the history, I will make the exact same mistakes again.

Rails pushes a bit to the convention of a read-through cache based on a tree of ActiveRecord objects. It uses an objects' updated_at timestamp to expire the its representation and the representation of all objects below in the tree.

This seems to work quite well for ERB templates and (possibly) also for JBuilder. That's why I think you can't go wrong with supporting people who structured their ActiveRecord models around Russian Doll Caching.

Looking at Jbuilder's implementation, this does not need to be complex at all: https://github.com/rails/jbuilder/blob/master/lib/jbuilder/jbuilder_template.rb

But maybe this approach is too naive.

What requirements does caching support for AMS need? 

[Matthijs Langenberg]

So I went ahead and implemented a caching strategy in my application.

Turns out, there is no significant speed improvement between serializing an array of ActiveRecord objects, and fetching the serialized attributes from a cache store such as Redis. Of course this is only the case when you do things right, and eager load all ActiveRecord models, before serializing.

What actually is more interesting is the huge speed up I measured when using caching to figure out which records to load from the database.

I understand that the following example is only applicable for my use case, and that's probably the reason why it is so hard to integrate a good caching solution in AMS.

Let's take the Facebook example, where every user has his own timeline with a list of posts, and every posts has one or more comments. We are trying to speed up the Posts#index action.

Instead of wrapping each call to AM::Serializer#serializable hash in a Rails.cach.fetch {} block. This approach is more successful: 

1) One database query to load posts for the current user in the correct order, but only select attributes needed to compute the cache key (id, updated_at). This is fast.

2) Do a cache.read_multi for with the cache keys for all posts. One roundtrip to Redis or Memcached.

3) Find out for which posts, we have a cache miss. Query Post.where(id: missing_ids) and join with all related tables (comments, users, etc). Forget ordering, ordering is expensive.

4) Serialize these ActiveRecord objects and store in cache.

5) Use result of original query to return serialized objects in correct order.

See https://gist.github.com/mlangenberg/10382475 for the implementation.

Please let me know what you all think of this approach.

- Matthijs

[Žiga Vidic]

This is how I cache for now http://blog.zigomir.com/active_model_serializers/rails/caching/2014/08/27/active-model-serializers-caching.html

On Friday, February 14, 2014 4:17:47 PM UTC+1, Raik Osiablo wrote:

[Tema Bolshakov]

Why not action cache?

27 авг. 2014 г., в 11:37, Žiga Vidic <zig...@gmail.com> написал(а):

--
You received this message because you are subscribed to the Google Groups "rails-api-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rails-api-cor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Klabnik]

The action cache was removed.

[João Moura]

Hey Matthijs,

Did you keep up working on a cache proposal to AMS?

I'm really interested on it too, so if you are working on that we could totally discuss it :) If not, just let me know how far you got on this so that I can try to keep it up too.

I'll take a deeper look at your gist, but I liked what you described, as u said, the deal would be find a way to abstract it.

Best,