Re: Newb question on static assets
This should be automatic. You can use some plugins like firebug to check headers. On Fri, Jan 27, 2012 at 8:32 AM, Carson Gross wrote: > 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 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 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 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 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 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 heroku@googlegroups.com. >> > To unsubscribe from this group, send email to >> > heroku+unsubscr...@googlegroups.com. >> > For more options, vis
Re: Newb question on static assets
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 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 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 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 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 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 heroku@googlegroups.com. > > To unsubscribe from this group, send email to > > heroku+unsubscr...@googlegroups.com. > > 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 heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubs
Re: Newb question on static assets
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 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 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 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 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 heroku@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com. > 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 heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Newb question on static assets
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 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 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 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 heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Newb question on static assets
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 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 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 heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Newb question on static assets
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 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 heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Newb question on static assets
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 heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
