Why could a start-up image not be saved and almost instantaneously
loaded from disk (like PC hibernation does) ?
Would this not totally replace the need for any idle instances ?
Where is the catch, considering how too obvious this is ;?)
On Sep 8, 6:07 am, Tim <meer...@gmail.com> wrote:
> Some of these threads are getting a bit long ("tl;dr"), but following Jon's
> interesting explanations of the "15 minute minimum" issue that has had many
> of us worried, let me try a brief explanation of how I see it working (I'm a
> user, not a Google employee, so take this with a pinch of salt until
> confirmed/refuted).
>
> - From when an instance starts, to when it dies, it is at any time in one
> of 3 states
> - ACTIVE: actively serving a request (ie from receiving an HTTP request
> until it finishes serving the HTTP response)
> - IDLE: inactive, not serving a request but still notionally allocated to
> a machine and in memory, will NOT be killed
> - FREE-IDLE: the process itself is in precisely the same state as "idle",
> but is NOT billed, and is eligible to be killed at any time
>
> - You are billed for total instance time of all instances in states
> "active" and "idle", but you are NOT billed for any time spent in "free
> idle" state
>
> - Only "free idle" instances are truly killed (other than failure, load
> balancing etc)
>
> - The "free idle" state is how GAE attempts to optimise scheduling and
> fault tolerance without thrashing etc without costing you anything
>
> The question now is how an instance starts, ends, and changes from one state
> to another.
>
> - An instance starts when either
> - it is needed to serve a request (there are no IDLE or FREE-IDLE
> instances available subject to max-pending-latency) - starts in ACTIVE state
> - or you have specified an "always-on" count - instances will start in
> IDLE state until "always-on" count is reached
> - with this regards to "always-on", I don't know if what you specify
> is a number of machines you in "ACTIVE or IDLE" state, or "ACTIVE or IDLE or
> FREE-IDLE" state
>
> - Any instance becomes ACTIVE when the scheduler allocates it a request to
> serve
>
> - An ACTIVE instance becomes IDLE when it finishes serving a request
> - (with concurrency, this is actually "when it is serving 0 requests")
>
> - An IDLE instance becomes FREE-IDLE when either
> - it has been IDLE for 15 consecutive minutes
> - or the number of IDLE instances exceeds your max-idle-instances count
> and this instance is chosen to become FREE-IDLE
> - or something within GAE (fault tolerance, load, outages) needs to
> otherwise kill your IDLE instance
> - that is, they can switch any IDLE instance to FREE-IDLE and then
> kill it at any time subject to their own discretion
>
> Now looked at in this way, you can see that "billed instance time" is not
> the same as "actual instance time" (what you see on your dashboard doesn't
> currently distinguish between IDLE and FREE-IDLE) but that "billed instance
> time" is essentially "time spent active serving a single request, including
> waiting for synchronous API calls to complete" plus "time spent in IDLE
> state". This is not the same "CPU cycles consumed", but more like "share of
> the capacity" (like paying for time in an internet cafe).
>
> But the big point is that the FREE-IDLE state is completely unbilled, and
> you have some control over when an instance enters this state - it's not
> true to say "all instances will be billed for a minimum of 15 minutes once
> started" as we all first heard, but you should instead see that "up to
> max-idle instances number of instances in the IDLE state will remain so for
> 15 minutes without activity before entering FREE-IDLE" state.
>
> So what's the point of IDLE state for you?
> Well, if you know you have a big startup time (hello Java) or you use
> in-process-memory state caching (rather than, say, memcache) then IDLE
> instances are your best friend, and you'll want to set a max-idle-instances
> sufficient to handle the rate of traffic increases for bursts, but if your
> startup time is minimal (hello python-with-webapp and handlers that only use
> memcache/datastore to preserve state) then IDLE instances deliver minimal
> benefit, and you'll want to set IDLE instances to a low number, maybe 1 or
> even 0 if GAE agree to allow such a setting.
>
> This mental model is what's put the smile back on my face ... here's hoping
> Jon and Greg don't come back to tell me I'm completely wrong...
>
> Cheers
>
> --
> Tim
--
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.
