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" <[email protected]> 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 <[email protected]>: > > > 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" <[email protected]> wrote: > > > Quoting badnaam <[email protected]>:> 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 [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
