Hi Oren, Thanks for the links. After reading through them, my best theory for the reason Chrome is aggressively reloading some resources I'd prefer that it didn't is because of the relatively recent Last-Modified headers coming from Varnish. Is there a way to tie the Last-Modified header back to when we last deployed?
Thanks, Carson On Jan 26, 10:22 pm, Oren Teich <[email protected]> wrote: > 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-talkhttp://www.slideshare.net/rtomayko/https-bestkept-secret-cachinghttp://tomayko.com/writings/things-caches-dohttp://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 > > athttp://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.
