Is it possible to take advantage of http caching/proxy caching with dynamic pages? i.e. pages with section/part that can change over time but certain part of the page remain the same. I would rather not keep re-rendering the static part but insure the dynamic part are rendered with fresh data. I am using memcached mostly as an object store that I can minimize db hits but I still am rendering a bunch of views over and over again. What''s the general best practice to deal with something like this.. ##Post controller def show @post = get_from_memcache end ##show.html.erb <div><%= post.body%></div> <div><%= post.created_at%></div> <div><%= post.category%></div> <div><%= Post.favorites_count%></div> The get_from_memcache return a @post object from a cache that basically doesn''t expire, because once a post is created, it''s body, category, created at etc remains the same. However, in my view I do call another method favorites_count which collects the posts''s favorites count from memcache and this favorite keeps changing. This is a simplication of course, there are a few fields that do change. Now If I were to implement some sort of http caching then I would need to do a fresh_when or stale? in my controller method (show), which would essentially not render the views and hence the updated favorites count, unless I use a etag that encompassed the favorite count and other dynamic fields, in which case it kinda defeats the purpose because those fields change regularly. How do I manage this situation? So I can take advantage of a proxy but keep certain dynamic fields in the page updated? One things I can think of is ajax calls to other controller actions to update those fields after page load, but that might ugly. Any other recommendations? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Quoting badnaam <asitkmishra-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:> Is it possible to take advantage of http caching/proxy caching with > dynamic pages? i.e. pages with section/part that can change over time > but certain part of the page remain the same. I would rather not keep > re-rendering the static part but insure the dynamic part are rendered > with fresh data. > > I am using memcached mostly as an object store that I can minimize db > hits but I still am rendering a bunch of views over and over again. > > What''s the general best practice to deal with something like this.. >[snip] If favorite_count is rendered at one end or the other, you can use fragment caching and memcache for the unchanging part. Or two fragments if favorite_count is in the middle. HTH, Jeffrey -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Yes, it seems the whole notion of etags, last_modified is pretty useless for even remotely dynamic pages. For example, let''s say If am shows a list of posts on a Post Index action. I can may be generate etags based on the Post count and send a 304 back, but if that page has a navbar that shows the current logged in users, even that information is not updated, it essentially it seems is telling the browser load the entire page for that action from cache. Don''t most apps similar structure (a username at the top, may be a badge or something that is specific to a logged in user), how would you etag these kind of pages? On Oct 4, 5:05 pm, "Jeffrey L. Taylor" <r...-f/t7CGFWhwGcvWdFBKKxig@public.gmane.org> wrote:> Quoting badnaam <asitkmis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:> Is it possible to take advantage of http caching/proxy caching with > > dynamic pages? i.e. pages with section/part that can change over time > > but certain part of the page remain the same. I would rather not keep > > re-rendering the static part but insure the dynamic part are rendered > > with fresh data. > > > I am using memcached mostly as an object store that I can minimize db > > hits but I still am rendering a bunch of views over and over again. > > > What''s the general best practice to deal with something like this.. > > [snip] > > If favorite_count is rendered at one end or the other, you can use fragment > caching and memcache for the unchanging part. Or two fragments if > favorite_count is in the middle. > > HTH, > Jeffrey-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
As you noted, etags et al doesn''t work for dynamic pages. You can use memcache for rendered fragments of a page as well as objects. Jeffrey Quoting badnaam <asitkmishra-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:> Yes, it seems the whole notion of etags, last_modified is pretty > useless for even remotely dynamic pages. For example, let''s say If am > shows a list of posts on a Post Index action. I can may be generate > etags based on the Post count and send a 304 back, but if that page > has a navbar that shows the current logged in users, even that > information is not updated, it essentially it seems is telling the > browser load the entire page for that action from cache. > > Don''t most apps similar structure (a username at the top, may be a > badge or something that is specific to a logged in user), how would > you etag these kind of pages? > > > > On Oct 4, 5:05 pm, "Jeffrey L. Taylor" <r...-f/t7CGFWhwGcvWdFBKKxig@public.gmane.org> wrote: > > Quoting badnaam <asitkmis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:> Is it possible to take advantage of http caching/proxy caching with > > > dynamic pages? i.e. pages with section/part that can change over time > > > but certain part of the page remain the same. I would rather not keep > > > re-rendering the static part but insure the dynamic part are rendered > > > with fresh data. > > > > > I am using memcached mostly as an object store that I can minimize db > > > hits but I still am rendering a bunch of views over and over again. > > > > > What''s the general best practice to deal with something like this.. > > > > [snip] > > > > If favorite_count is rendered at one end or the other, you can use fragment > > caching and memcache for the unchanging part. Or two fragments if > > favorite_count is in the middle. > > > > HTH, > > Jeffrey > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Yes I guess that might be the case. the scaling rails screencasts about advanced http caching led me to think that most high traffic web sites use etag extensively for reverse proxy caching. On Oct 4, 6:10 pm, "Jeffrey L. Taylor" <r...-f/t7CGFWhwGcvWdFBKKxig@public.gmane.org> wrote:> As you noted, etags et al doesn''t work for dynamic pages. You can use > memcache for rendered fragments of a page as well as objects. > > Jeffrey > > Quoting badnaam <asitkmis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: > > > Yes, it seems the whole notion of etags, last_modified is pretty > > useless for even remotely dynamic pages. For example, let''s say If am > > shows a list of posts on a Post Index action. I can may be generate > > etags based on the Post count and send a 304 back, but if that page > > has a navbar that shows the current logged in users, even that > > information is not updated, it essentially it seems is telling the > > browser load the entire page for that action from cache. > > > Don''t most apps similar structure (a username at the top, may be a > > badge or something that is specific to a logged in user), how would > > you etag these kind of pages? > > > On Oct 4, 5:05 pm, "Jeffrey L. Taylor" <r...-f/t7CGFWhwGcvWdFBKKxig@public.gmane.org> wrote: > > > Quoting badnaam <asitkmis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:> Is it possible to take advantage of http caching/proxy caching with > > > > dynamic pages? i.e. pages with section/part that can change over time > > > > but certain part of the page remain the same. I would rather not keep > > > > re-rendering the static part but insure the dynamic part are rendered > > > > with fresh data. > > > > > I am using memcached mostly as an object store that I can minimize db > > > > hits but I still am rendering a bunch of views over and over again. > > > > > What''s the general best practice to deal with something like this.. > > > > [snip] > > > > If favorite_count is rendered at one end or the other, you can use fragment > > > caching and memcache for the unchanging part. Or two fragments if > > > favorite_count is in the middle. > > > > HTH, > > > Jeffrey > > > -- > > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.