Hi Mauricio,

Yes I understand that, and we've been working on it. Sorry that it's taking
long.

Hi Wilson,

It's coming with the pricing change. Since we started charging with number
of instances, we needed to provide more control on how we spin-up a new
instances.
In other words, if we continued the old behavior, many developers would
have complained like "App Engine spins up unnecessary instances.".

We believe that it makes more sense when warmup requests are used only for
resident idle instances.

-- Takashi


On Sat, Jul 14, 2012 at 7:18 AM, Wilson MacGyver <wmacgy...@gmail.com>wrote:

> any reason behind this change? this seems kind of strange. I too was
> wondering by the
> behavior till you posted this. I had my min set to automatic also
>
> On Fri, Jul 13, 2012 at 9:28 AM, Takashi Matsuo <tmat...@google.com>
> wrote:
> >
> > Now the warmup requests are fired only if you set min idle instances to
> some
> > value(not automatic).
> >
> > -- Takashi
> >
> >
> > On Fri, Jul 13, 2012 at 9:52 PM, Michael Hermus <
> michael.her...@gmail.com>
> > wrote:
> >>
> >> Same for me.. I just checked: no calls to warmup, lots of loading
> >> requests.
> >>
> >> **shakes fist at App Engine**
> >>
> >>
> >> On Thursday, July 12, 2012 4:39:48 PM UTC-4, Tom Phillips wrote:
> >>>
> >>> Interesting..I checked and I too have 100% of my loading requests on
> >>> user facing URLs instead of /_ah/warmup.
> >>>
> >>> Warmup requests are enabled and Automatic-Automatic for both instance
> >>> sliders.
> >>>
> >>> I used to see at least a decent percentage of loading requests on /_ah/
> >>> warmup, but haven't looked in quite a while.
> >>>
> >>> /Tom
> >>>
> >>> On Jul 12, 3:46 pm, David Hardwick <david.hardw...@bettercloud.com>
> >>> wrote:
> >>> > Some additional observations and questions...
> >>> >
> >>> > After reading this [Link 1] stack overflow article that mentioned an
> >>> > issue with having your Max Idle count below 6, we started looking at
> >>> > our warmup request on our staging environment because that app-id has
> >>> > Idle Instances set to Auto-Auto, while production had specific
> values.
> >>> >
> >>> > But...Where did all the "/_ah/warmup" requests go?  When doing a
> label
> >>> > search for these staging environment logs ["path:/_ah/warmup" (doing
> a
> >>> > label search)] we couldn't find any warmup request!!(yes, we have
> >>> > warmup requests turned on)...we would just see the first cold-start
> >>> > request would take around 15 seconds to load (F1) and 10 seconds to
> >>> > load on (F2).
> >>> >
> >>> > I even shut down every instance and hit the staging server again to
> >>> > see if I could find a warmup request in the logs...nope.  Honestly, I
> >>> > would rather have a user wait 10 seconds for the first request to
> that
> >>> > server as opposed risking the warmup requests failing again.
> >>> >
> >>> > Where did all the "/_ah/warmup" requests go?   More importantly, why
> >>> > would we have such different times for warmup requests compared to
> >>> > cold starts?  Shouldn't they be nearly identical?!
> >>> >
> >>> > Rock on,
> >>> >   -Hardwick
> >>> >
> >>> > [Link 1]
> >>> > -
> http://stackoverflow.com/questions/9422698/ah-warmup-producing-hardde...
> >>> >
> >>> > On Jul 12, 12:26 pm, David Hardwick <david.hardw...@bettercloud.com>
> >>> > wrote:
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > > Hello,
> >>> >
> >>> > > I realize there's been a lot of discussion on startup times
> exceeded
> >>> > > on
> >>> > > this forum recently, but wanted needed to post this experience we
> had
> >>> > > this
> >>> > > morning to keep the attention on this important issue.
> >>> >
> >>> > > We uploaded a point release of our app to a "not-live" version this
> >>> > > morning
> >>> > > and, of course, we were going to click around on that instance to
> >>> > > make sure
> >>> > > it's all kosher before making that version "live."   The warm-up
> >>> > > requests
> >>> > > for the "not-live" version were exceeding the deadline limit of
> >>> > > 60s...
> >>> > > __and__we__are__on__F4s__!_!.
> >>> >
> >>> > > However, the LIVE version of the app crashed too, 500 server
> errors,
> >>> > > instance counts went to zero, all sorts of whacky stuff was seen in
> >>> > > the
> >>> > > control panel.  All that happened to our LIVE version without when
> >>> > > all we
> >>> > > did was upload another "non-live" version and hit it with a single
> >>> > > request...did I mention we were on F4s?  ;-)  Does the failure of
> any
> >>> > > instance to exceed the 60s limit take down all instances to include
> >>> > > live
> >>> > > one?
> >>> >
> >>> > > We did a few things as quickly as possible since our live
> application
> >>> > > was
> >>> > > down, so clearly we didn't have the time to take the scientific
> >>> > > approach of
> >>> > > only changing one thing at a time and wait to see if it that did
> it.
> >>> >
> >>> > > We...
> >>> > > 1. Switched from F4s to F2 (i figured if this would least get us on
> >>> > > some
> >>> > > new servers/instances)
> >>> > > 2. Increased max idle instances from 1 to 2 (with F4s running, I'm
> >>> > > fine
> >>> > > with having just 1 idle instance and not at all happy about paying
> >>> > > for 2
> >>> > > idle instances, so maybe we'll just increase this prior to
> >>> > > deployments and
> >>> > > then back down again after the deployment succeeds until we know
> >>> > > more)
> >>> > > 3. Made the recently uploaded version live (hey, why not, the
> >>> > > production
> >>> > > app was down for 10 minutes, so how much more harm could we do?)
> >>> >
> >>> > > We use GWT and Guice, we jar everything (as I have been paying
> >>> > > attention to
> >>> > > this startup time discussions for quite some time now.  We are also
> >>> > > considering switching our Guice libraries to a non-AOP version as
> we
> >>> > > saw
> >>> > > suggested in another blog since we just need the injection.
> >>> >
> >>> > > Any insight, and I'm all ears!  app_id=s~myflashpanel
> >>> >
> >>> > > Regards,
> >>> > >   -Hardwick
> >>> >
> >>> > > --
> >>> >
> >>> > >  *We make Google Apps even better.*
> >>> >
> >>> > > *David Hardwick*
> >>> > > *CTO*
> >>> > > david.hardw...@bettercloud.com
> >>> >
> >>> > > *Signature by Flashpanel <http://flashpanel.com/>*
> >>> > >  *See us in Mashable: Growing Up Google: How Cloud Computing Is
> >>> > > Changing a
> >>> > > Generation
> >>> > > <http://mashable.com/2012/04/30/generation-growing-up-google/>*
> >>
> >> --
> >> 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/-/Bs6JKwLYDAMJ.
> >>
> >> 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
> >
> > --
> > 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.
>
>
>
> --
> Omnem crede diem tibi diluxisse supremum.
>
> --
> 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

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

Reply via email to