There are different types of caches - client and server side. Check out this presentation to learn more about what's going on:
http://tomayko.com/writings/railsconf-caching-talk http://www.slideshare.net/rtomayko/https-bestkept-secret-caching http://tomayko.com/writings/things-caches-do http://tomayko.com/writings/rack-cache-announce Oren On Thu, Jan 26, 2012 at 9:53 PM, Carson Gross <[email protected]> wrote: > And one last note: due to the way some of these resources are included > (e.g. the stylesheet_link_tag method in rails) they end up with a > query string. > > Reading online, it appears that resources with a query string are not > supposed to be cached, but that the major browsers ignore that. > > Anyone know for sure? > > Thanks, > Carson > > On Jan 26, 9:41 pm, Carson Gross <[email protected]> wrote: >> OK, now that I have my head around what is going on, it appears that >> the static stuff is being cached and served up via Varnish. >> >> It appears that my browser is not respecting the varish response >> though. The response has the following header: >> >> Cache-Control:public, max-age=43200 >> >> and yet another request is made when I hit cmd-r. When I click >> around, I still see requests for this resource, with the 304 response >> code. >> >> I'm using Chrome. >> >> UPDATE: >> >> OK, digging a bit more, I found this page: >> >> http://code.google.com/speed/page-speed/docs/caching.html >> >> In particular, I note this bit: >> >> "Set the Last-Modified date to the last time the resource was changed. >> If the Last-Modified date is sufficiently far enough in the past, >> chances are the browser won't refetch it." >> >> And, looking more closely at the response headers, I see this: >> >> Cache-Control:public, max-age=43200 >> Connection:keep-alive >> Date:Fri, 27 Jan 2012 05:31:46 GMT >> Last-Modified:Thu, 26 Jan 2012 17:14:44 GMT >> Server:nginx >> Via:1.1 varnish >> X-Varnish:800861986 >> >> And note that the Last-Modified date is today, even though we haven't >> deployed a new version of our app for a while, which I believe may be >> why Chrome is issuing requests for the resources even though it isn't >> changing. >> >> When I resubmit, I see a different Last-Modified header for the same >> resource. >> >> So my guess here is that the Last-Modified header is generated by the >> change date of the file on a particular instance of Varnish, and that >> various instances are coming up and going down, causing the Last >> Modified date to be relatively recent, causing Chrome to submit more >> requests to the server than I'd like. >> >> Does that sound at all plausible? >> >> Thanks, >> Carson >> >> On Jan 26, 5:56 pm, Carson Gross <[email protected]> wrote: >> >> >> >> >> >> >> >> > Looking at it a bit more (as well as some *yikes* requests to our >> > server) I see that we are getting a ton of 304s, which are, no doubt, >> > tying up our dynos. >> >> > So, this may be more of a rails question than a heroku question, but >> > how can I set expires headers on certain static directories? >> >> > Yes, I am a complete and utter newb at this. >> >> > Cheers, >> > Carson >> >> > On Jan 26, 5:00 pm, Carson Gross <[email protected]> wrote: >> >> > > Heya, >> >> > > Sorry, digging through the docs I couldn't really get an answer on >> > > this that I understand: >> >> > > So, with static assets, deployed on the bamboo-ree-1.8.7 stack, are >> > > static assets served by web dynos? As our application has grown over >> > > time, we've evolved to issue a horrific number of requests for static >> > > content (css, javascript, etc.) and I'm trying to understand just how >> > > bad that is for our performance. Seems like we'd be tying up web >> > > dynos, but I want to make sure. >> >> > > Secondly, given that I don't feel like rewriting all that code right >> > > now, is there a way to map certain paths to a heroku app to another >> > > server, so we aren't hammering our dynos so badly? >> >> > > Thanks, >> > > Carson > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" 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/heroku?hl=en. > -- You received this message because you are subscribed to the Google Groups "Heroku" 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/heroku?hl=en.
