Blobstore v.s static file serving

[Ubaldo Huerta]

I wonder what's the prescribed way to serve an asset image (say, a site logo)

1-The easy way, using static handlers specified in app.yaml

2-Uploading them via the blobstore api

I realize that 1 is simpler to do but I wonder if the fact that doing it via blobstore it would be served faster.  For one thing, it comes from a different domain and the request comes back without cookies. Now, is there a difference in cost?

[andreas schmid]

why should the blobstore be faster?

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/fVSpDS4gRBoJ.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

[Barry Hunter]

On Fri, Sep 9, 2011 at 4:13 PM, andreas schmid <a.sch...@gmail.com> wrote:
> why should the blobstore be faster?

http://code.google.com/appengine/docs/python/images/overview.html#Transforming_Images_from_the_Blobstore

and get_serving_url()

> On Sep 9, 2011, at 5:02 PM, Ubaldo Huerta wrote:
>
> I wonder what's the prescribed way to serve an asset image (say, a site
> logo)
> 1-The easy way, using static handlers specified in app.yaml
> 2-Uploading them via the blobstore api
> I realize that 1 is simpler to do but I wonder if the fact that doing it via
> blobstore it would be served faster.  For one thing, it comes from a
> different domain and the request comes back without cookies. Now, is there a
> difference in cost?

You will have to pay a bit for storage in the blobstore, where in
effect static storage is free.

Otherwise bandwidth usage is the same.

Another benefit of static is you can explicitly set caching headers -
for both the edge-cache and the browser cache. The blobstore urls,
have a default caching header I beleive - but you cant set a really
long caching time.

Also static requests can follow you around on version automatically
(ie different version so a app will get different files automatically)
whereas that will have to be done manually with the blobstore.

[andreas schmid]

that still does not answer why an image retrieved form the blobstore should be faster than one served as a static file.

[Barry Hunter]

On Fri, Sep 9, 2011 at 4:49 PM, andreas schmid <a.sch...@gmail.com> wrote:
> that still does not answer why an image retrieved form the blobstore should be faster than one served as a static file.

As aluded to in the original question, the big one is cookieless

http://developer.yahoo.com/performance/rules.html#cookie_free

And possibly the 'infestructure' used for serving images - its used by
picasa and blogger etc too - is more distributed than static requests
for appengine.

The static requests for appengine, probably still come from the
appengine datacenters, where hopefully the serving url is more
distributed globally. But dont know for sure :)

[Ubaldo Huerta]

I also imagine that the the infrastructure for blobstore api is distributed, etc, etc, and that intermediate proxy caches are are better tuned to the etag, etc, etc it does. Objects in the blobstore are inmutable so I'm not sure why I get the following expires headers (for tomorrow) with a test image below. Note that the 304 status code was nicely returned.

Anyhow, with the static serving you have to explicitly put your expiration policy in yaml. I will the documentation where more clear (and more assertive) about the blobstore api. Some spots in app engine get little love, email api being another (it's very flaky, prone to errors). Now, with the quota reduction makes me wonder if it's worth the trouble to use an external mail server, I think so :-(

1. Request URL:
   http://lh4.ggpht.com/O9EJJF2UKj4th8hDYoU7_Ew6MTtqw_Ngvbk-mZ6d7gn90pcVD1aylNOu_Icj_0ccEmSCseVuE0Qu94iQ7R8PSx2-=s580
2. Request Method:
   GET
3. Status Code:
   304 Not Modified
4. Request Headersview source
1. Accept:
   text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
2. Accept-Charset:
   ISO-8859-1,utf-8;q=0.7,*;q=0.3
3. Accept-Encoding:
   gzip,deflate,sdch
4. Accept-Language:
   en-US,en;q=0.8
5. Cache-Control:
   max-age=0
6. Connection:
   keep-alive
7. Host:
   lh4.ggpht.com
8. If-None-Match:
   "v1"
9. User-Agent:
   Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
5. Response Headersview source
1. Age:
   162
2. Date:
   Fri, 09 Sep 2011 18:56:10 GMT
3. ETag:
   "v1"
4. Expires:
   Sat, 10 Sep 2011 18:56:10 GMT
5. Server:
   GFE/2.0

 h 

[N. Rosencrantz]

I think that get_serving_url can be better than something like /static/images... if not for performance then for convenience and consistency to serve blobs from the blobstore. I think get_serving_url and blobstore are very good projects not only for performance but also convenience and that get_serving_url could continue to add more image functions like filters and/or processing and also for audio and video so that we can upload uncompressed media and serve it compressed via appengine and python libraries (while many multimedia codecs depend on C we could see more codecs in the future with python/java or Go).

I thought it could be good to use the blobstore like a filesystem so now I've got both a handler for blobstore:

/file

As well as my old handlers that serve static files I redploy with the application

/images
/img
/static/(js|css|...)
/_

If your static files are video or images that need resizing you might want to use the blobstore instead of including them in the project directory. I asked myself this too not only for performance reasons but also convenience i.e. putting source code in the datastore and/or blobs in the blobstore treating my application images like I treat user's uploaded images which would have the convenience of ability to change the upload with no redeployment.

I think blobstore can be an alternative for anything that is a "file" especially since it already has image resize and might get more functions like conversion etc so we don't have to reinvent basic stuff like image resize and
I hope google adds more functions to get_serving_url especially for media files like audio and video.

Wouldn't it be good if you could upload for instance uncompressed audio or video to blobstore and you could serve it with different codecs and different compression i.e. just add the parameter mp3 to the get_serving_url and then you'd get the output in mp3 and all you'd do is use the builtin functions.

Best regards,
Niklas

[Barry Hunter]

On Fri, Sep 9, 2011 at 8:07 PM, Ubaldo Huerta <uba...@gmail.com> wrote:

Objects in the blobstore are inmutable so I'm not sure why I get the following expires headers (for tomorrow) with a test image below.

I think its because they allow you to delete the blob, which deletes the image. 

With an expires header, even after you delete, it would appear the image is still there - served from various caches. 

So a shortish expires, means the image can be 'deleted' within about 24 hours. 

Even after the expires, well expires, the 304's should still be used - and the 304 itself is cachable for a further 24 hours :)

(So bandwidth usage should still be low)