On Mon, Sep 29, 2008 at 11:18 AM, Arun Shanker Prasad <[EMAIL PROTECTED]> wrote: > > My app is also causing the same problems, I have used etags to set the > response to 302 if cached, I've tried everything short of memcache, I > have many images, I don't think that is a viable solution for me.
Why not? memcache is 'free', doesn't seem to be any reason NOT to use it? memcache is already designed to keep 'hot' items in the cache - so it will automatically discard little used images (or what ever you store). You should I would of thought be looking to cache everything possible. > > Any suggestions are welcome. > > On Sep 29, 2:10 am, iceanfire <[EMAIL PROTECTED]> wrote: >> Thanks for the suggestions. I see the need for Cacheing to reduce the >> load, but I don't understand why the current request is causing high- >> cpu warnings (2 times the average cpu request). At this rate, if a few >> first time users use my application & try to open images that haven't >> been memcached (etc..).. then my application will crash. >> >> My main question is: why is this request causing a high cpu warning, >> and no one has been able to answer that. For a request that only >> takes "0.020 CPU seconds" (according to profiler), appengine sends >> out a warning stating that 2463mcycles have been used. >> >> So my question is: how do I completely stop high-cpu warnings for a >> request that shouldn't be causing them in the first place? >> >> I understand that there are ways I can mitigate the problem..but i'd >> like to get to the root if possible. >> >> thanks! >> >> On Sep 25, 9:26 am, "Bryan A. Pendleton" <[EMAIL PROTECTED]> wrote: >> >> > -So are textProperties more efficient than StringProperties >> > because >> > they're not indexed? >> >> > You'd have to find the talk from Google IO to be sure. I believe >> > it >> > was the one about scalability, in the QA section. But yes, that is >> > my >> > understanding. >> >> > As I understand it, every field that's not a TextProperty or a >> > BlobProperty are implicitly indexed (this is how all = conditions are >> > dealt with in queries). So, whenever you write such an object, it will >> > take longer (because of the index updates). >> >> > Another way of thinking about it, is that if you never need to query >> > on a single value, make it a TextProperty or BlobProperty, if >> > possible. >> >> > -Wouldn't adding etag--while increasing efficiency if I have the >> > same >> > users loading the sameimageagain and again--actually decrease >> > efficiency for users who are opening up an thumbnail for the first >> > time? In that situation, I'd have another column for etags in my >> > datastore being requested w/ every query. >> >> > Yes, you absolutely should generate the etag when you save the >> > thumbnail, and save it in the model itself.Cachingit separately >> > is >> > however still desirable as you can then avoid pulling the rest of >> > the >> > data into memory if it's not needed, or you can opt to not cache >> > the >> > rest of the data at all, instead onlycachingthe etag, to be more >> > cache friendly. >> >> > A quick and easy hack for this is to generate the etag before creating >> > the Thumbnail model instance - and use that etag as the named key. >> > Then, you can do lookup andcachingbased on the etag alone, where >> > that makes sense. Unless you have some specific meaning in your ID >> > already, this should simplify the "how to deal with etags" question >> > quite a bit. > > > -- Barry - www.nearby.org.uk - www.geograph.org.uk - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
