That is not quite the behavior I observe.  It largely looks like this:

 - I1 is warm and ready
 - the request comes in
 - the request goes to I2 and blocks while it starts up
 - another request comes, goes to I3 and blocks while it starts up

While it's not 100%, GAE seems to route a disturbing number of
requests (say, 1 out of 10)  to not-warmed-up instances.  Just
clicking around the site produces large numbers of UX delays while an
instance starts.  The dashboard often shows three instances.  This is
in java with threadsafe-true and F1 instances and not particularly
CPU-intensive operations; my requests do a lot of data operations and
almost all have <1s latency.

This is with the setting at 1 min idle, 1 max idle.  I've disabled
billing on my sandbox app so I can't experiment anymore - I'm not
willing to try this experiment on production.  I was still seeing this
behavior a week ago.  Switching to Auto/Auto, I almost never see more
than one instance and startup requests are nearly absent from the
logs.

I understand that min idle instances tries to keep them idle in
reserve.  The problem is that the reserve doesn't seem to get used.  I
can't think of any rationale for routing a user request to an instance
startup while there is idle capacity just sitting by.  Or even if it
isn't idle that second, it will be in short order - waiting 1s is
better than waiting 20s for a whole instance.

Jeff

On Thu, Mar 15, 2012 at 3:54 AM, Gregory D'alesandre <[email protected]> wrote:
> Hey Jeff,
>
> The way it is supposed to work with min idle instances set is:
> - idle instance is warm and ready (let's call it I1)
> - request comes in
> - request goes to the idle instance at which point another instance is
> immediately spun up (let's call it I2)
> - you now have 1 idle instance (I2) as well as 1 instance serving traffic
> (I1)
>
> I know it might seem like we are taking the label too literally but we are
> trying to maintain idle capacity for you.  The tricky part is since we
> always spin up a new idle instance when an existing one begins to serve
> traffic it looks like they are sitting around unused when they are in fact
> being used often just others immediately take their place.  Are you sure
> this is not the behavior your are observing?
>
> Thanks,
>
> Greg
>
> On Wed, Mar 14, 2012 at 8:00 AM, Jeff Schnitzer <[email protected]> wrote:
>>
>> On Wed, Mar 14, 2012 at 4:28 AM, Tapir <[email protected]> wrote:
>> >
>> > On Mar 14, 1:17 pm, Gopal Patel <[email protected]> wrote:
>> >> you mean, always have one instance more than required ? ( who is going
>> >> to
>> >> pay for that ? ) , and is not minimum idle instance same thing ?
>> >
>> > It is different with the normal resident instance.
>> > It is an instance to handle requests only at the time of the situation
>> > "no available instances and need create a new instance",
>> > so that many "Cold Starts" can be avoided.
>>
>> This is pretty much exactly what setting minimum idle instances does.
>> Requests are preferentially routed to dynamic instances rather than
>> resident instances.
>>
>> The problem is, something in the scheduler is broken.  Instead of
>> routing requests to the idle instance, GAE prefers to route requests
>> to a fresh instance, causing the user to wait while an instance warms
>> up.  That setting is probably best described as "minimum useless
>> instances".  Maybe somebody took the "minimum _idle_ instances" label
>> too literally ;-)
>>
>> This is the behavior I observed a week or two ago.  Hopefully it will
>> be fixed.  Doesn't sound like it has been so far.
>>
>> Jeff
>>
>> --
>> 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.
>>
>
> --
> 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.

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