Jan,

I hope the GAE team corrects me if I'm wrong, but I wouldn't worry too
much in your case, especially if you've tuned the requests to consume
minimal CPU.

The way things are right now, if each of your requests takes 50ms, (of
which 10ms is actual CPU and the rest is waiting)  then one GAE
instance can serve 1000 / 50 = 20 requests a second. So you'll be
paying (we all think) for three instances, plus the startup / shutdown
overhead.

What most of us are forgetting is that threading will be introduced to
coincide with the pricing changes (hopefully :D), so when that happens
one instance will actually serve 1000 / 10 = 100 requests a second. So
things might not be as bad as you think, especially if you've
optimized your app to consume less CPU than what I'm calculating. In
this case you might not even notice the changed pricing from a CPU
point of view.

This is approximate, of course, but you get the idea. Things might not
be as bad as you think, and your CPU optimizations will probably
continue to serve you well. Let's wait a bit and see what the actual
situation is.

Sudhir

On May 30, 12:05 pm, "Jan Z/ Hapara" <[email protected]> wrote:
> This change penalizes "spiky" apps in a huge way.
>
> Three years ago, when we first started with GAE, we did so for three
> reasons:  1) scalability 2) pay for what you use model, and 3)
> SIMPLICITY.
>
> Our app is very "spiky" - a single user will at times generate 50+
> concurrent requests that need to be served quickly.   We've spent
> three years working around the GAE to fine-tune the code and work
> within the scalability and other constraints, and it works remarkably
> well.  There is not a chance that we could get as far if we had to use
> EC2 or other systems.
>
> The new pricing model has two implications for us: a) we will start
> paying mostly for idle instances and b) we lose the simplicity and
> predictability of the existing model.   It seems that you're shifting
> the "hard" problem here back to the users, and that's a shame.
>
> As others have suggested, the new scheduler needs to have the
> flexibility to cater to small and tight apps - in not providing it you
> are penalizing the very people who embraced your tools first and
> worked hard around your early limitations and teething problems.
>
> Jan

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