Almost identical setup and observations. In addition,
We are observing that one instance with very few warmups (spin offs of new instances) can be achieved with min instances = auto and max = 1. Our traffic is not that much ~ 1 QPS with mostly < 1 s latency Thanks Prashant On 15-Mar-2012, at 8:53 PM, Jeff Schnitzer wrote: > 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. > -- 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.
