I saw the same behavior (as discussed before in the thread). Many other people reported this again and again on this mailing-list. Google has to acknowledge that the current implementation is buggy or the implementation works but doesn't make any sense in practice.
Bye the way - The problem is not restricted to resident instances. From time to time the same happens for dynamic instances: One or more dynamic instances are running and are almost idle (sometimes really idle==no request or just one request is served). Request comes and starts a new dynamic instance, it goes through 30-40 seconds of warmup, then request is served. On Mon, Aug 27, 2012 at 5:19 PM, Carl D'Halluin <c...@mobicage.com> wrote: > Hi Carl, > > I see exactly the same behaviour for my Java appengine app. > Resident instance does nothing; instead idle instance is started, going > through several seconds of warmup, then request is served. > > Regards > > > On Mon, Aug 27, 2012 at 5:11 PM, Carl Schroeder < > schroeder.car...@gmail.com> wrote: > >> 2012-08-27 08:05 is the point in the logs. 1 Resident instance. No >> Dynamic instances. >> The request was sent to a cold starting Dynamic instance. Resident >> instance did nothing. >> Request took 18 seconds to serve. >> >> >> On Monday, August 27, 2012 2:16:25 AM UTC-7, Johan Euphrosine (Google) >> wrote: >> >>> On Mon, Aug 27, 2012 at 5:59 AM, Carl Schroeder >>> <schroede...@gmail.com> wrote: >>> > Let me see if I understand this correctly: there is currently no way >>> on app >>> > engine to ensure that there is an instance ready to process incoming >>> > requests for an app that has been idle for some period of time. Min >>> idle >>> > instances (labeled as Resident) sit there and do almost nothing while >>> user >>> > facing requests are instead sent to cold instance starts. If true, >>> that >>> > dovetails with what I have seen in the behavior of my app. For python >>> > runtimes with sub-second spinup times, this is no big deal. For java >>> > runtimes with spinup times in double digit seconds it is a >>> deal-breaker of a >>> > "feature". >>> > >>> > The problem seems to be that the scheduler thinks sending a request to >>> a >>> > non-existent dynamic instance is a better idea than using the Resident >>> > instance for it's intended purpose: to serve requests when dynamic >>> instances >>> > are unable to. This is probably a corner case born of low traffic >>> conditions >>> > that allow user request serving dynamic instances to despawn. >>> >>> Hi Carl, >>> >>> That's not what we observed, as I corrected in the previous email: >>> """ >>> Resident instances are used for processing incoming request if there >>> is no dynamic instance, but it is possible that the scheduler warm up >>> new dynamic instance to maintain the Min Idle Instance invariant. >>> """ >>> >>> If you observe a different behavior please comment with your >>> application id and the timestamp of occurence and we can try to figure >>> out what happened. >>> >>> Thanks in advance. >>> >>> > >>> > For low traffic apps, "Resident" instances serve almost no purpose. >>> Better >>> > to do away with them via the slider bars and just set up a script to >>> tickle >>> > the app just often enough to keep one "Dynamic" instance resident. >>> > >>> > So, two features to fix this: >>> > First, a slider bar labeled "Minimum Dynamic instances" ;) >>> > Second, a button to enable sending warm-up requests and having them >>> return >>> > before considering an instance for user facing requests. >>> > >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "Google App Engine" group. >>> > To view this discussion on the web visit >>> > https://groups.google.com/d/**msg/google-appengine/-/**G4DPOlW2Jh8J<https://groups.google.com/d/msg/google-appengine/-/G4DPOlW2Jh8J>. >>> >>> > >>> > To post to this group, send email to google-a...@googlegroups.**com. >>> > To unsubscribe from this group, send email to >>> > google-appengi...@**googlegroups.com. >>> > For more options, visit this group at >>> > http://groups.google.com/**group/google-appengine?hl=en<http://groups.google.com/group/google-appengine?hl=en>. >>> >>> >>> >>> >>> -- >>> Johan Euphrosine (proppy) >>> Developer Programs Engineer >>> Google Developer Relations >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/google-appengine/-/ApT6E62dU9QJ. >> >> 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. >> > > > > -- > Carl D'Halluin > > Next-generation communication at http://www.rogerthat.net > > Email: c...@mobicage.com > Phone: +32 9 324 25 64 > Fax: +32 9 324 25 65 > Skype: carldhalluin > Twitter: @carl_dhalluin > LinkedIn: http://www.linkedin.com/pub/carl-d-halluin/0/982/457 > > NV MOBICAGE > Antwerpsesteenweg 19 > 9080 Lochristi > Belgium > > -- 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.
