Could you please spare us from the explanations of what the real world is like?

My test case is this: there's an app that is just a noop wsgi app
(webob.Response('pong')). It is not under any load. There's a
different GAE app that urlfetches it once a minute on a cron schedule.
I am looking at the logs of the first app and the graphs on the
dashboard, and the time / request and even cpu / request vary wildly.
See attachment.

Remember, this is an app that does absolutely nothing.

Such variability isn't perfect but is OK, if I only pay for the CPU
used -- if at some point the host running the app is too busy to
actually run my code, I'm fine with a new instance serving the
concurrent requests. But when I have to pay for this, it's not OK at
all.

Frankly, I'm not too happy that every request takes ~15ms even when
the luck is on my side, cause I know the app itself doesn't take even
that long to execute, but that's not the issue here.

Anyway, your comparisons are wrong.

-Sergey

On 19 May 2011 02:01, Brandon Wirtz <[email protected]> wrote:
> 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: [email protected]
> [mailto:[email protected]] 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 <[email protected]> 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 [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.
>
>



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

<<attachment: 2011-05-19_021148.png>>

Reply via email to