[google-appengine] Re: Incredible traffic saving with the header Cache-control: public???
Quizás quisiste decir: A mi no me aparece esto. Puede garantizar que la diferencia entre cache-control private y public es que con public Escribe texto o la dirección de un sitio web o traduce un documento. Cancelar Escuchar traducción del español al inglés I do not look like this. I can guarantee that the cache-control difference between private and public is that public away 95% of traffic, almost all. However, this is served 100% ok to customers. The traffic is not on any chart, or if the consumption of bandwidth or in the logs. On 15 dic, 03:29, Albert albertpa...@gmail.com wrote: Hi! This guy seems to implement something similar to yours, but he says, ...each time a page is served cached, you'll see a 204 logged in your Appengine dashboard. http://www.kyle-jensen.com/proxy-caching-on-google-appengine Did any of you guys notice that too? Albert On Dec 15, 9:29 am, GONZO gonzom...@gmail.com wrote: Hi, thanks for your response. I like your answer. Just what I expected. Confirms my theory and my experiences. I confirm that requests saved (90%) do not appear in the logs and not counted in the consumption of bandwidth. It's free total. Amazing. I appreciate all the information you know about it. Thank you all. Greetings! On 8 dic, 03:51, Jason Collins jason.a.coll...@gmail.com wrote: Cache-Control: private only uses the end user cache to cache resources. Cache-Control: public uses any downstream cache to cache resources (including the browser cache). Google has a downstream cache in front of App Engine requests, so if you serve your resources with Cache-Control: public, Google will cache that resource. Subsequent hits are served from there, and I'm pretty sure they won't even show in your request log at all. j On Dec 6, 3:19 pm, GONZO gonzom...@gmail.com wrote: Hi, first thanks for your attention and sorry for my English translation. I have a question that intrigues me a few weeks. This is the header cache-control in particular the behavior of the options private and public in Google App Engine. First of all, this is only to serve static files (css, js, etc) Let's go. With cache-control: private experiment curve normal traffic. But with cache-control: public experiment Traffic incredible savings. In both cases, everything seems to work well. The question is: 1. How can traffic be a big savings? Is reduced to 15%. 2. Saving you a real traffic? Or is something special instead of Google App Engine? Better look at this diagram illustrates:http://gonzo.teoriza.com/almacen/cache-control.jpg Thanks in advance, I hope to be clarified. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Incredible traffic saving with the header Cache-control: public???
Hi, thanks for your response. I like your answer. Just what I expected. Confirms my theory and my experiences. I confirm that requests saved (90%) do not appear in the logs and not counted in the consumption of bandwidth. It's free total. Amazing. I appreciate all the information you know about it. Thank you all. Greetings! On 8 dic, 03:51, Jason Collins jason.a.coll...@gmail.com wrote: Cache-Control: private only uses the end user cache to cache resources. Cache-Control: public uses any downstream cache to cache resources (including the browser cache). Google has a downstream cache in front of App Engine requests, so if you serve your resources with Cache-Control: public, Google will cache that resource. Subsequent hits are served from there, and I'm pretty sure they won't even show in your request log at all. j On Dec 6, 3:19 pm, GONZO gonzom...@gmail.com wrote: Hi, first thanks for your attention and sorry for my English translation. I have a question that intrigues me a few weeks. This is the header cache-control in particular the behavior of the options private and public in Google App Engine. First of all, this is only to serve static files (css, js, etc) Let's go. With cache-control: private experiment curve normal traffic. But with cache-control: public experiment Traffic incredible savings. In both cases, everything seems to work well. The question is: 1. How can traffic be a big savings? Is reduced to 15%. 2. Saving you a real traffic? Or is something special instead of Google App Engine? Better look at this diagram illustrates:http://gonzo.teoriza.com/almacen/cache-control.jpg Thanks in advance, I hope to be clarified. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Incredible traffic saving with the header Cache-control: public???
Hi! This guy seems to implement something similar to yours, but he says, ...each time a page is served cached, you'll see a 204 logged in your Appengine dashboard. http://www.kyle-jensen.com/proxy-caching-on-google-appengine Did any of you guys notice that too? Albert On Dec 15, 9:29 am, GONZO gonzom...@gmail.com wrote: Hi, thanks for your response. I like your answer. Just what I expected. Confirms my theory and my experiences. I confirm that requests saved (90%) do not appear in the logs and not counted in the consumption of bandwidth. It's free total. Amazing. I appreciate all the information you know about it. Thank you all. Greetings! On 8 dic, 03:51, Jason Collins jason.a.coll...@gmail.com wrote: Cache-Control: private only uses the end user cache to cache resources. Cache-Control: public uses any downstream cache to cache resources (including the browser cache). Google has a downstream cache in front of App Engine requests, so if you serve your resources with Cache-Control: public, Google will cache that resource. Subsequent hits are served from there, and I'm pretty sure they won't even show in your request log at all. j On Dec 6, 3:19 pm, GONZO gonzom...@gmail.com wrote: Hi, first thanks for your attention and sorry for my English translation. I have a question that intrigues me a few weeks. This is the header cache-control in particular the behavior of the options private and public in Google App Engine. First of all, this is only to serve static files (css, js, etc) Let's go. With cache-control: private experiment curve normal traffic. But with cache-control: public experiment Traffic incredible savings. In both cases, everything seems to work well. The question is: 1. How can traffic be a big savings? Is reduced to 15%. 2. Saving you a real traffic? Or is something special instead of Google App Engine? Better look at this diagram illustrates:http://gonzo.teoriza.com/almacen/cache-control.jpg Thanks in advance, I hope to be clarified. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Incredible traffic saving with the header Cache-control: public???
Hi Gonzo, If you have a lot of authenticated users the difference you are seeing is probably in the cached authenticated requests. From http://www.mnot.net/cache_docs/: My pages are password-protected; how do proxy caches deal with them? By default, pages protected with HTTP authentication are considered private; they will not be kept by shared caches. However, you can make authenticated pages public with a Cache-Control: public header; HTTP 1.1-compliant caches will then allow them to be cached. If you’d like such pages to be cacheable, but still authenticated for every user, combine the Cache-Control: public and no-cache headers. This tells the cache that it must submit the new client’s authentication information to the origin server before releasing the representation from the cache. This would look like: Cache-Control: public, no-cache Whether or not this is done, it’s best to minimize use of authentication; for example, if your images are not sensitive, put them in a separate directory and configure your server not to force authentication for it. That way, those images will be naturally cacheable. On Dec 6, 4:19 pm, GONZO gonzom...@gmail.com wrote: Hi, first thanks for your attention and sorry for my English translation. I have a question that intrigues me a few weeks. This is the header cache-control in particular the behavior of the options private and public in Google App Engine. First of all, this is only to serve static files (css, js, etc) Let's go. With cache-control: private experiment curve normal traffic. But with cache-control: public experiment Traffic incredible savings. In both cases, everything seems to work well. The question is: 1. How can traffic be a big savings? Is reduced to 15%. 2. Saving you a real traffic? Or is something special instead of Google App Engine? Better look at this diagram illustrates:http://gonzo.teoriza.com/almacen/cache-control.jpg Thanks in advance, I hope to be clarified. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Incredible traffic saving with the header Cache-control: public???
yes, incredible savings. Need to include a version number or hash tag in the URL to ensure that new versions get pushed in sync. An example: http://bbfdirect.com/ I'm working on the next level, which is enable cache-control for the HTML itself, i.e. render the page and then make AJAX calls to fetch the dynamic content, and detect out-of-date HTML using the AJAX calls. My lead eng thinks I'm psycho and I probably am. We're starting with cache-control: private on that stuff, but if I can resolve the issues with proxies serving cached data during javascript:window.reload(true), then we'll go public FTW. wish me luck (we went live with the private version yesterday), adam On Dec 7, 10:07 am, Erik erik.e.wil...@gmail.com wrote: Hi Gonzo, If you have a lot of authenticated users the difference you are seeing is probably in the cached authenticated requests. Fromhttp://www.mnot.net/cache_docs/: My pages are password-protected; how do proxy caches deal with them? By default, pages protected with HTTP authentication are considered private; they will not be kept by shared caches. However, you can make authenticated pages public with a Cache-Control: public header; HTTP 1.1-compliant caches will then allow them to be cached. If you’d like such pages to be cacheable, but still authenticated for every user, combine the Cache-Control: public and no-cache headers. This tells the cache that it must submit the new client’s authentication information to the origin server before releasing the representation from the cache. This would look like: Cache-Control: public, no-cache Whether or not this is done, it’s best to minimize use of authentication; for example, if your images are not sensitive, put them in a separate directory and configure your server not to force authentication for it. That way, those images will be naturally cacheable. On Dec 6, 4:19 pm, GONZO gonzom...@gmail.com wrote: Hi, first thanks for your attention and sorry for my English translation. I have a question that intrigues me a few weeks. This is the header cache-control in particular the behavior of the options private and public in Google App Engine. First of all, this is only to serve static files (css, js, etc) Let's go. With cache-control: private experiment curve normal traffic. But with cache-control: public experiment Traffic incredible savings. In both cases, everything seems to work well. The question is: 1. How can traffic be a big savings? Is reduced to 15%. 2. Saving you a real traffic? Or is something special instead of Google App Engine? Better look at this diagram illustrates:http://gonzo.teoriza.com/almacen/cache-control.jpg Thanks in advance, I hope to be clarified. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Incredible traffic saving with the header Cache-control: public???
Cache-Control: private only uses the end user cache to cache resources. Cache-Control: public uses any downstream cache to cache resources (including the browser cache). Google has a downstream cache in front of App Engine requests, so if you serve your resources with Cache-Control: public, Google will cache that resource. Subsequent hits are served from there, and I'm pretty sure they won't even show in your request log at all. j On Dec 6, 3:19 pm, GONZO gonzom...@gmail.com wrote: Hi, first thanks for your attention and sorry for my English translation. I have a question that intrigues me a few weeks. This is the header cache-control in particular the behavior of the options private and public in Google App Engine. First of all, this is only to serve static files (css, js, etc) Let's go. With cache-control: private experiment curve normal traffic. But with cache-control: public experiment Traffic incredible savings. In both cases, everything seems to work well. The question is: 1. How can traffic be a big savings? Is reduced to 15%. 2. Saving you a real traffic? Or is something special instead of Google App Engine? Better look at this diagram illustrates:http://gonzo.teoriza.com/almacen/cache-control.jpg Thanks in advance, I hope to be clarified. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.