Rails - etags vs. page caching (file cache)

前端 未结 3 578
长发绾君心
长发绾君心 2021-02-06 03:06

What would be some advantages of using etags/stale?/fresh_when? instead of page caching (on a file cache)?

Apache automatically handles etags for static files, but even

相关标签:
3条回答
  • 2021-02-06 03:43

    They are really complimentary. Etags/fresh_when etc. help you play nice with downstream caches (like your own Varnish/Squid instances or Rack::Cache or the Browser cache or ISP Proxy Servers…)

    Page caching saves you from hitting your rails stack entirely because Apache/your webserver serve the file, so no DB lookups are done. But you have to deal with cache expiration to keep the cache fresh.

    Using etags/conditional get, you don't save much processing time since you still need to to get all the records used on the page:

    def show
      @article = Article.find(params[:id])
      @feature = Feature.current
      fresh_when :etag => [@article, @feature] 
    end
    

    in the case that the user has a current page, it saves you some rendering time and the bandwidth required to send down the page.

    0 讨论(0)
  • 2021-02-06 03:44

    Another use that occurred to me was that you could still process some information before letting Rails hand out the "304 Not Modified" header. Like if you want to record hits to a page.

    0 讨论(0)
  • 2021-02-06 04:05

    One thing that comes to mind is that fresh_when will still save you some rendering even if you cleared the entire page cache. Here you'd be using both in tandem.

    I'm curious about other answers as well.

    0 讨论(0)
提交回复
热议问题