5 ms·

The additional datastore call and also the CPU time spent in the script (even though it might be minimal) are totally unnecessary. Just upload the files yoursel

by stwe 16y ago

The additional datastore call and also the CPU time spent in the script (even though it might be minimal) are totally unnecessary. Just upload the files yourself and serve them statically. Even though it's not a true CDN (as discussed in many places many times), it works good enough. And why do call it Google Application Engine? Google itself calls it just App Engine.

symkat 16y ago
I'm going to reply to this with a copypaste from what I said in response to a similar question on reddit: That’s an excellent question. While I thought of this solution as well, I choose not to use it. Here are three key reasons I choose to do it this way instead: Speed While it can be argued that serving the files statically will cause an increase in speed, due to the script itself not being loaded, this is questionable. Google does not do 304 negotiations, and uses cache-control: no-cache when serving static files. These default settings will increase the amount of requests sent to GAE, and cause the browser to do more work, and handle more bandwidth for any user who loads a page more than once. My solution supports 304 negotiations on both sides of the cache. Control Serving the files statically gives up control of the HTTP headers. SymPullCDN forwards all headers from the origin. By using the static file handlers you give up the ability to control some important headers, such as Cache-Control and Expires. Usability I’m using SymPullCDN side-by-side with wordpress. It’s caching files from my origin, and wordpress is sending all requests for /wp-include/, /wp-content/, and /s/ (static files) to SymPullCDN. If I change the template, add static files to the site, or do anything else (installing plugins, for instance) I don’t want to have to investigate which files are in my origin that are not on the cache side, download them to my laptop and upload them to google. Having the cache downloading from my origin is a crucial usability issue for me. At the end of the day, this is something I wrote for myself, to meet the needs I have; however, I feel others might find useful, so I released it to GitHub and did a little write up about it.

by stwe 16y ago

symkat 16y ago

I'm going to reply to this with a copypaste from what I said in response to a similar question on reddit: That’s an excellent question. While I thought of this solution as well, I choose not to use it. Here are three key reasons I choose to do it this way instead: Speed While it can be argued that serving the files statically will cause an increase in speed, due to the script itself not being loaded, this is questionable. Google does not do 304 negotiations, and uses cache-control: no-cache when serving static files. These default settings will increase the amount of requests sent to GAE, and cause the browser to do more work, and handle more bandwidth for any user who loads a page more than once. My solution supports 304 negotiations on both sides of the cache. Control Serving the files statically gives up control of the HTTP headers. SymPullCDN forwards all headers from the origin. By using the static file handlers you give up the ability to control some important headers, such as Cache-Control and Expires. Usability I’m using SymPullCDN side-by-side with wordpress. It’s caching files from my origin, and wordpress is sending all requests for /wp-include/, /wp-content/, and /s/ (static files) to SymPullCDN. If I change the template, add static files to the site, or do anything else (installing plugins, for instance) I don’t want to have to investigate which files are in my origin that are not on the cache side, download them to my laptop and upload them to google. Having the cache downloading from my origin is a crucial usability issue for me. At the end of the day, this is something I wrote for myself, to meet the needs I have; however, I feel others might find useful, so I released it to GitHub and did a little write up about it.