Regarding differences in pricing based on Differences in Latency:

Welcome to the real world.  

Did you know that when you buy Gasoline on a day that is 10 below zero, you
get 30% more energy per gallon (and dollar) than when you buy on a 114
degree day?  Do they charge less for gasoline on Hot days?

When the 85 pound skinny little Asian girl that is my best friend comes to
visit and doesn't have any checked bags flies she is 110 pounds of cargo,
but they charge her as much as the 250 pound guy with two 55 pound checked
bags and a 25 pound carry on even though she is 1/3 the weight.

The Buffet at Circus Circus is all you can eat, but I don't get a discount
if the family of 6 sumo wrestlers are in line ahead of me and eats all of
the prime-rib before I can get to it.

Oh, and the only variability I have seen is not tied to nodes, or instances
it was tied to if I get good rolls of the dice on my caching and data store
look ups.  But I could probably write some test code to see if different
instances have variability between them performance wise.  I would just have
to test with sever app Id's so that I could tell if I had the same
instances.  (also variability probably gets lessened by me having 100+
instances across my apps at almost all times)

-Brandon


-----Original Message-----
From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of nickmilon
Sent: Wednesday, May 18, 2011 3:42 PM
To: Google App Engine
Subject: [google-appengine] Re: FAQ for out of preview pricing changes

@Sergey good questions.
IMHO this is a sisyphean task, new policy has opened Pandora's box with
questions popping up from it in a much faster rate that can be answered.
Nick

On May 18, 11:06 pm, Sergey Schetinin <ser...@maluke.com> wrote:
> A couple more questions for the FAQ:
>
> 1) What are the expected limits on the concurrency for Python 2.7 
> instances? Assuming the requests handlers / threads are just waiting 
> for RPC to finish (say on urlfetch service), how many per-process are 
> allowed? This is probably still TBD, but a ballpark figure would be 
> very welcome.
>
> 2) How the keys-only queries will be charged for?
>
> 3) What controls are in place to make sure that the instances do not 
> get stuck on a bad / slow host? I have experienced very different 
> response times from a noop WSGI app hosted on GAE, and given the costs 
> will now be tied very directly to the latency, how can you make us 
> comfortable with the fact that this latency is volatile and often 
> completely out of our control? (or remove the volatility)
>
> 4) Can we have some assurance that the hosts are not oversold and the 
> CPU / Memory quota is actually guaranteed? Volatility in response 
> times (as measured by the GAE dashboard itself) suggests that 
> different hosts are under a different load and sometimes the 
> instance's process has to wait to get to run on a CPU. (When a no-op 
> app sometimes runs in 10ms and sometimes in 300ms+, that doesn't look 
> like guaranteed CPU to me).
>
> 5) Can we configure scheduler to shut instances down faster than in 15 
> minutes? (And not get charged for that idle time). If not, please 
> justify this limitation.
>
> 6) Will we have a way to explicitly shut down an instance from the 
> instance itself? (Without returning an error, basically to suggest to 
> scheduler that "this is the last request I want to handle")
>
> 7) Will the pricing become stable after this change? How can you 
> assure us that it will?
>
> 8) Is there any intention to adjust the prices in a year or two to 
> account for falling hardware prices?
>
> Thank you.
>
> -Sergey
>
> PS I also wanted to mention to people asking if GIL will be removed -- 
> of course it will stay. Also, there's no need to remove it, so please 
> don't make random requests and learn what GIL is and why it's there. I 
> would bet that the concurrency will be via regular Python threads (no 
> multiprocessing), but the app itself would not be allowed to spawn or 
> control those threads.
>
> --http://self.maluke.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.

Reply via email to