If the scheduler worked right there wouldn't be the insane number of Idle
instances.  Even if there is a 1/12 of the time that runs at 12x the volume
should look like:

1
1
1
12

So the average should be 4x mode.  

As I see it there is no reason to need a "Max Idle Instances" only a "max
queue time".
You know that most browsers will give up if they haven't gotten any data in
30s  so 30,000 ms is easily the ceiling.
The interface only allows for 15s, so using that as a ceiling.

Spin Up: If Queue is > Max Que Spin up new instance.
Variant "Economy" Spin-up: If x% of requests have Queue time > max Queue
Spin up new instance.

SpinDown:
Billing is in 15 minute intervals, so you can look at the Load over the last
5 minutes and determine how many instances to kill.

This is how every load balancer / Cloud balancer on the planet works (except
GAE)

If CPU % On Current Instance > X
         {
        Goto Next Instance
        If Last instance in Chain
                {
                Spin New Instance
                }
        }

Since App Engine isn't parallel  Rather than CPU Load, you look at Serial
Task queue, and how many customers are in line.

A good scheduler would be multi-pass, if you have a "problem customer" (one
that is taking 5s when the average is 500ms) you would take other requests
from the line and drop them in to other instances.  (This is really what
Idle instances should be for)

I still see the problem with the scheduler being that we are not specifying
a QoS we are specifying at throttle. (and the throttle is tied to some very
weird math, that isn't documented anywhere)





-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Jon McAlister
Sent: Wednesday, September 07, 2011 7:02 PM
To: [email protected]
Subject: Re: [google-appengine] Re: the min instace time is 24 hours?

Hi Vivek,

It's a good point. The most simple advice I'd have for you is to follow this
rubric:

   (1) If you're unhappy with the cost, reduce max-idle-instances.
   (2) If you're unhappy with the serving latency and reliability, increase
max-idle-instances.

I think that's really all that most developers should need to do.

There are also lots of optimizations that could made to any app (e.g.
concurrency of the runtime or the task queue or the api calls, use memcache,
use http caching, use high-replication datastore), and these have always
been good things to do, but at a certain point there are diminishing returns
on how much can be achieved with these.

On Wed, Sep 7, 2011 at 6:21 PM, Vivek Puri <[email protected]> wrote:
> Folks, reading all the posts(to be true, i read only the first 10 of 
> this thread), it seems everyone where is expected to be a GAE billing 
> expert to survive. Although all the discussions sound interesting, i 
> dont really have the time to understand all the intricacies, and i 
> believe same is the case for other developers. Personally, sole reason 
> for choosing GAE was that i can focus on my business model and not 
> about balancing set of servers and the billing. It would have been way 
> better and easier if you had increased the CPU, bandwidth, storage 
> price to cover up for revenues. If you look at AWS, they have never 
> done this drastic change in the their service and pricing model. Every 
> new product comes with its pricing and stackable in some fashion onto 
> existing products.
>
> GAE team still has the chance to cancel this change and let everyone 
> get back to their core job, their application. Please dont make it an 
> ego issue, if there is still a chance to cancel this change. Just for 
> comparison, Facebook had cancelled its Facebook Beacon product in 2007 
> after putting in tons and tons of effort and partnerships into it. And 
> as far as i can recall, the amount of resistance to Beacon product was 
> much less than what i have seen with GAE pricing change.
>
> --
> You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
[email protected].
> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
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 [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Reply via email to