Try making a page that consists of more than a single request to the 
server. A burst of requests that is served (not static content) under the 
pending latency time would usually trigger an instance spin-up. 
Now that spin-up times are back to normal, I am not seeing this behavior 
nearly as often.


On Wednesday, August 29, 2012 6:07:30 PM UTC-7, Takashi Matsuo (Google) 
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 
> <je...@infohazard.org<javascript:>
> > 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 
>> <tma...@google.com<javascript:>
>> > 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 
>>> <schroede...@gmail.com<javascript:>
>>> > 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-a...@googlegroups.com<javascript:>
>>>> .
>>>> To unsubscribe from this group, send email to 
>>>> google-appengi...@googlegroups.com <javascript:>.
>>>> For more options, visit this group at 
>>>> http://groups.google.com/group/google-appengine?hl=en.
>>>>
>>>
>>>
>>>
>>> -- 
>>> Takashi Matsuo | Developers Advocate | tma...@google.com <javascript:>
>>>
>>>  -- 
>>> 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-a...@googlegroups.com<javascript:>
>>> .
>>> To unsubscribe from this group, send email to 
>>> google-appengi...@googlegroups.com <javascript:>.
>>> 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-a...@googlegroups.com<javascript:>
>> .
>> To unsubscribe from this group, send email to 
>> google-appengi...@googlegroups.com <javascript:>.
>> For more options, visit this group at 
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>
>
>
> -- 
> Takashi Matsuo | Developers Advocate | tma...@google.com <javascript:>
>
>  

-- 
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/-/dvslL-9S_hAJ.
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.

Reply via email to