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 [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
-~----------~----~----~----~------~----~------~--~---

Reply via email to