I just wanted to follow up on this discussion to (shamefacedly) point out what was causing this problem: imports.
I had copied and pasted some code earlier, which I had later deleted to slim down my code. What I had forgotten to do was: remove the imports for that piece of code. Once I had removed them, I noticed a great improvement in performance. Ever since I removed that piece of code + changed debug to false and removed the profiler code, I haven't had any cpu warnings for that particular piece of code. So the lesson here is: If you're having trouble reducing your CPU warnings, try looking at imports and make sure that you only call the essential ones. On Oct 1, 2:24 am, iceanfire <[EMAIL PROTECTED]> wrote: > I will try removing the debug stuff, maybe that is what's causing this > problem. I'll let you know if this helps. > > Thanks. > > On Sep 29, 6:44 am, Sylvain <[EMAIL PROTECTED]> wrote: > > > Hi, > > > memcache can decrease the average, that's all. > > memcache is really good, but it can't be the answer for everything. > > > Else, I think with this CPU/Warning, there is no "good" solution. Now, > > I'm just waiting for higher quota (free or not). > > > Did you remove all "DEBUG" flag (webapp, django render option,...) > > because it uses a lot of CPU. > > The profiler code uses a lot of CPU too. > > > Regards > > > On 29 sep, 12:57, Arun Shanker Prasad <[EMAIL PROTECTED]> > > wrote: > > > > Hi Barry, > > > > I know that the memcache is free, but it will push out stuff if the > > > memory usage is high, I already have much bigger query result cached > > > in the memcache, I want to keep them there as long as possible. :) > > > > Thanks, > > > Arun Shanker Prasad. > > > > On Sep 29, 3:44 pm, "Barry Hunter" <[EMAIL PROTECTED]> > > > wrote: > > > > > 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 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 -~----------~----~----~----~------~----~------~--~---
