Thanks Brandon, I probably mis-communicated. I'm not doing any image manipulation. On- line handler receives the jpeg bytes posted by client and saves them in a db.BlobProperty entity property. When the call for the jpeg comes in, handler simply does a get_by_id, and writes out the db.BlobProperty value.
The image call is pretty much exactly like the example at Google's docs page, but without the query, just the get_by_id: http://code.google.com/appengine/articles/python/serving_dynamic_images.html Did a little testing today, and am pretty sure the cpu variations are due to my limited volumes. Below are three consecutive image gets. Notice how only the first one (which came after a period of inactivity) has the high cpu total. I had thought paying to have the on-line handler resident avoided that startup cpu costs for the first activity after a period of non- acitivity. Just not groking that I think. So for now a non-issue I think. My minute volumes are never going to approach using my CPU daily quote even if every image get averages 13,000ms. If volumes start to rise, clearly the number of startup cpu instances falls. Thanks again, Steve *****Log Extract underscores preceding cpu ms***** << subsequent calls >> 2011-05-15 12:36:10.357 /cardimage/80002.jpg 200 201ms_____66cpu_ms 8api_cpu_ms 2011-05-15 12:36:04.040 /cardimage/73005.jpg 200 312ms_____63cpu_ms 8api_cpu_ms << startup call >> 2011-05-15 12:35:56.980 /cardimage/74003.jpg 200 204ms_____2427cpu_ms 8api_cpu_ms On May 14, 3:20 pm, "Brandon Wirtz" <[email protected]> wrote: > Well Duh, You are generating a JPG, you said "send the bytes" but you are > modifying, rendering, and compressing a JPG. That takes some CPU. -- You received this message because you are subscribed to the Google Groups "Google App Engine" 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/google-appengine?hl=en.
