thanks marzia, thats what I needed to hear.
On Feb 26, 12:33 pm, Marzia Niccolai wrote:
> Hi,
>
> To clarify, this is based on runtime CPU, not datastore CPU. Also, this
> shouldn't affect the serving status of your application, it just means that
> your app may see some additional latency on a
Hi,
To clarify, this is based on runtime CPU, not datastore CPU. Also, this
shouldn't affect the serving status of your application, it just means that
your app may see some additional latency on a per request basis if it is
serving a large number of CPU intensive requests.
-Marzia
On Tue, Feb
I wouldn't worry about 100-300ms requests being sidelined until and
unless I saw it happening. I realize I also may have been unclear
before: I was measuring response times, not CPU time, if that helps.
--~--~-~--~~~---~--~~
You received this message because you are
thanks for info Nick, I realize I'm probably looking too deeply into
your explanation above. I thought you had said it was not instance
startup cost (which had me concerned), although I know it can be
difficult to debug/profile what is actually happening.
of more concern to me is marzia's comment
Thanks for following through on this, Marzia! That makes a lot more
sense. I really appreciate the diagnosis; you rock!
bFlood, I think the only reason that handler is getting mauled is
because of the 1200ms+ startup costs for initializing a new instance.
Because it's the same handler, the startu
hi marzia
ok, can you confirm these new limits? previously, most people designed
their apps to run in the 100-300ms range (datastore access included).
when you started to go over 300ms, the warnings would start to show up
in the logs. suffice it to say, it was reasonable to assume when no
warning
well that seems like a change from previous posts. I thought people
generally quoted 200-300ms as a safe place to be for most of your
requests
On Feb 24, 4:13 pm, Marzia Niccolai wrote:
> Hi,
>
> 20ms is not considered CPU intensive, but once you get up in to the
> hundreds, it is.
>
> -Marzia
>
Hi,
20ms is not considered CPU intensive, but once you get up in to the
hundreds, it is.
-Marzia
On Tue, Feb 24, 2009 at 5:43 AM, bFlood wrote:
>
> thanks marzia
>
> I dont want to read too much into Nick's results above but is 30-200ms
> now considered to be CPU intensive?
>
> cheers
> brian
thanks marzia
I dont want to read too much into Nick's results above but is 30-200ms
now considered to be CPU intensive?
cheers
brian
On Feb 23, 4:20 pm, Marzia Niccolai wrote:
> Hi,
>
> This is done on a per-request basis.
>
> -Marzia
>
> On Mon, Feb 23, 2009 at 12:14 PM, bFlood wrote:
>
> >
Hi,
This is done on a per-request basis.
-Marzia
On Mon, Feb 23, 2009 at 12:14 PM, bFlood wrote:
>
> hi marzia
>
> when this occurs, is the temp governor set for the entire app? or just
> the handler that caused the high CPU warning? above, Nick said that
> the typical request was 30-200ms so
hi marzia
when this occurs, is the temp governor set for the entire app? or just
the handler that caused the high CPU warning? above, Nick said that
the typical request was 30-200ms so it seems odd that it would be
throttled
I think this is better then the original high CPU reaction (throw
excep
Hi,
Upon some further investigation, it seems that this is the result of the new
handling of CPU intensive requests, more information about which can be
found here:
http://code.google.com/appengine/docs/quotas.html#Request_Limits
Specifically "Applications that are heavily cpu-bound, on the other
12 matches
Mail list logo
