I really do wish I had time right now to help track this down - believe me, this issue is very relevant to my interests!
Jeff On Wed, Aug 29, 2012 at 9:07 PM, Takashi Matsuo <tmat...@google.com> wrote: > > Jeff, > > Thanks for the suggestion, and probably that's true. I've chosen this test > from Mos's e-mail, because I got a feeling that he saw odd behaviors even > with one request per minute. Hopefully I can do another test based on your > suggestion soon. > > Please note that you can also provide your test result on our issue > tracker and help us reproduce the issue :) > > Thanks, > > > On Thu, Aug 30, 2012 at 9:16 AM, Jeff Schnitzer <j...@infohazard.org>wrote: > >> This is not a very good test. Better would be: Run 'ab -c 1' against it >> and see if you get any cold starts. Change 1 to a larger number, up to >> what concurrency we should expect for a multithreaded instance. >> >> Jeff >> >> >> On Wed, Aug 29, 2012 at 6:54 PM, Takashi Matsuo <tmat...@google.com>wrote: >> >>> >>> Hi Mos and everyone, >>> >>> I'm trying to reproduce the issue about min idle instance which some of >>> you guys reported here in this thread, saying "Setting min idle instances >>> doesn't work for me". >>> >>> My initial test is just with a simple helloworld Java application >>> multithread enabled, setting 1 min idle instance, and setting 1 min cron >>> job. I ran this test for about 2 and half days. I think it just worked as >>> expected. The resident instance had been alive and handled 3625 requests >>> during the test. >>> >>> What I'm planning to do next is another experiment with an application >>> with Spring MVC. I'll update with the result hopefully next week. >>> >>> At the same time, I'd like one of you to file an issue on our issue >>> tracker for this particular topic, 'Setting min idle instances doesn't >>> work', hopefully with expected behavior, actual results, a characteristic >>> of the application like average time for loading requests as well as normal >>> requests, etc. I've done a quick search on our issue tracker, and I don't >>> think there's any issue yet. If there's already an issue about it, please >>> let me know. >>> >>> Thanks, >>> >>> >>> On Tue, Aug 28, 2012 at 2:13 AM, Carl Schroeder < >>> schroeder.car...@gmail.com> wrote: >>> >>>> Yep. Googlites, let us know what else you need to run this down. >>>> >>>> >>>> On Monday, August 27, 2012 10:05:41 AM UTC-7, Mos wrote: >>>> >>>>> In http://code.google.com/p/**googleappengine/issues/detail?** >>>>> id=8004#c8<http://code.google.com/p/googleappengine/issues/detail?id=8004#c8> >>>>> I described in detail a current example of the nonconforming >>>>> instance-handling of GAE. >>>>> Please check the comment, the screenshot and the log-file I filed >>>>> there. >>>>> >>>>> Dear GAE-Team, what else do you need to fix this? In this thread and >>>>> in several issues you should have more than enough proof and examples..... >>>>> >>>>> Cheers >>>>> Mos >>>>> >>>>> On Mon, Aug 27, 2012 at 5:34 PM, Mos <mos...@googlemail.com> wrote: >>>>> >>>>>> 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 >>>>>> <ca...@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 < >>>>>>> schroede...@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/**ms**g/google-appengine/-/** >>>>>>>>> G4DPOlW2J**h8J<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<https://groups.google.com/d/msg/google-appengine/-/ApT6E62dU9QJ> >>>>>>>> . >>>>>>>> >>>>>>>> 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> >>>>>>>> . >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Carl D'Halluin >>>>>>> >>>>>>> Next-generation communication at http://www.rogerthat.net >>>>>>> >>>>>>> Email: ca...@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<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 view this discussion on the web visit >>>> https://groups.google.com/d/msg/google-appengine/-/kb9OyMgMH5wJ. >>>> >>>> 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. >>>> >>> >>> >>> >>> -- >>> Takashi Matsuo | Developers Advocate | tmat...@google.com >>> >>> -- >>> 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. >> > > > > -- > Takashi Matsuo | Developers Advocate | tmat...@google.com > > -- > 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.
