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 same image again 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. Caching it 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 only caching the 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 and caching based 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. --~--~---------~--~----~------------~-------~--~----~ 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-appengine@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
