Right now, I have the :action_suffix for a fragment I cache such that I can find it when I need to delete it from the cache. But an episode on Rails Casts gave the idea that another approach is to not worry about deleting the old fragments. They will eventually just get pushed out of the cache. Instead, just make sure that the name is unique to the version of the object(s) for which the fragment renders. So, the suggestion was to make the :action_suffix tied to the last update field or an equivalent field. Can anyone comment on this strategy? It seems much easier to me. It somewhat solves the problem of trying to kill the old cache entries with all the ugly sweeper logic. -- Posted via ruby-forum.com.
> Right now, I have the :action_suffix for a fragment I cache such > that I > can find it when I need to delete it from the cache. But an episode > on > Rails Casts gave the idea that another approach is to not worry about > deleting the old fragments. They will eventually just get pushed > out of > the cache. Instead, just make sure that the name is unique to the > version of the object(s) for which the fragment renders. > > So, the suggestion was to make the :action_suffix tied to the last > update field or an equivalent field. > > Can anyone comment on this strategy? It seems much easier to me. It > somewhat solves the problem of trying to kill the old cache entries > with > all the ugly sweeper logic.Seems reasonable. As long as you''re sure your cache will expire the old entries and not keep piling them up until you run out of ram/disk space. I would consider adding a generic method to all your models named say "fragment_key" that does whatever is necessary to generate a unique key. That way in your controllers/views you never have to think what fields to put in there to get the right version. It''s always just @instance.fragment_key. And you can hash that if you want to shorten it down and avoid any key length issues or invalid characters, etc. You might also find this interesting... blog.plataformatec.com.br/2009/09/how-to-avoid-dog-pile-effect-rails-app -philip
Philip Hallstrom wrote:> > Seems reasonable. As long as you''re sure your cache will expire the > old entries and not keep piling them up until you run out of ram/disk > space. >I''m using memcache. I''ll research and double check and make sure it just pushes things out the cache. The alternative would be to have them expire after a few days. Thanks for the link too. -- Posted via ruby-forum.com.
On Oct 2, 2009, at 11:26 AM, Perry Smith wrote:> > Philip Hallstrom wrote: >> >> Seems reasonable. As long as you''re sure your cache will expire the >> old entries and not keep piling them up until you run out of ram/disk >> space. >> > > I''m using memcache. I''ll research and double check and make sure it > just pushes things out the cache. The alternative would be to have > them > expire after a few days.Memcache will push things out of the cache to make room for new items.
Would the built-in lock_version magic column be good enough for a fragment_key? On Oct 2, 1:09 pm, Philip Hallstrom <phi...-LSG90OXdqQE@public.gmane.org> wrote:> > Right now, I have the :action_suffix for a fragment I cache such > > that I > > can find it when I need to delete it from the cache. But an episode > > on > > Rails Casts gave the idea that another approach is to not worry about > > deleting the old fragments. They will eventually just get pushed > > out of > > the cache. Instead, just make sure that the name is unique to the > > version of the object(s) for which the fragment renders. > > > So, the suggestion was to make the :action_suffix tied to the last > > update field or an equivalent field. > > > Can anyone comment on this strategy? It seems much easier to me. It > > somewhat solves the problem of trying to kill the old cache entries > > with > > all the ugly sweeper logic. > > Seems reasonable. As long as you''re sure your cache will expire the > old entries and not keep piling them up until you run out of ram/disk > space. > > I would consider adding a generic method to all your models named say > "fragment_key" that does whatever is necessary to generate a unique > key. That way in your controllers/views you never have to think what > fields to put in there to get the right version. It''s always just > @instance.fragment_key. And you can hash that if you want to shorten > it down and avoid any key length issues or invalid characters, etc. > > You might also find this interesting...http://blog.plataformatec.com.br/2009/09/how-to-avoid-dog-pile-effect... > > -philip