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.
