There are a couple of things you can still do:

   - Try always to send high expensive operations to the background (task
   queues). And also an expensive operation does not mean a lot of processing
   time in your side. If you notice your API CPU usage is high, this could be a
   delete/put operation on an Entity that has, either many indexes, exploding
   problems or data contention due to a not well designed entity group. A
   simple delete/put could take a lot of time or create a bottleneck in your
   application.
   - Don't burst out the task queue operations, play around with the Stored
   Task Queue bytes and tasks execution rate, try to find the limit of tasks
   per second for a operation before it creates contention problems.

Doing so, we were able to diagnose the limits on terms of request per second
of our system (protecting it by task queues) and now we take those alarms as
new designs we need to apply for that specific resource to consume less and
split it in different executions. Just to give you a reference, we load
tested a resource pretty much in the same conditions as yours, and we are
able to scale it 10x times what it does right now before the serving cluster
warned us with throttling. But dont take this as a "this would go beyond, i
would not worry" but as a notice to keep looking for new
designs/architectures.


On 12 March 2011 00:19, Robert Kluin <robert.kl...@gmail.com> wrote:

> lp,
>  If you haven't already, you might want to use Appstats to verify
> that the variations are not actually caused by RPC calls.
>
>  Always on doesn't mean you'll never get a loading request; instances
> have to be started, which will be a loading request.  If you get
> enough traffic to need additional instances you could see loading
> requests (they are indicated in the logs).
>
>
>
>
> Robert
>
>
>
>
> On Fri, Mar 11, 2011 at 22:59, lp <lucio.picc...@gmail.com> wrote:
> >> So my question is, should I be concerned at the high CPU warnings or
> >> is it something most people experience?
> >
> >
> > i am getting similar CPU times and very similar elapsed times as u.
> >
> > but i get large variation in my CPU times for no apparent reason
> > ( same query, params).
> > i am using 'Always-on' so it cant be warm up request.
> >
> > all that i am concerned about is my elapsed time and my quota cost for
> > scalability..... so far so it can scale.
> >
> >
> > -lp
> >
> > --
> > 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
> google-appengine+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
> >
> >
>
> --
> 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
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>
>


-- 
http://about.me/david.mora

-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Reply via email to