The new pricing model charges are based on the number of instances you have running. This is largely dictated by the App Engine Scheduler, but for Python we will not be supporting concurrent requests until Python 2.7 is live. Because of this, and to allow all developers to adjust to concurrent requests, we have reduced the price of all Frontend Instance Hours by 50% until November 20th.
Our app (python runtime) is going from about $9 a month to projected $270 a month, almost entirely due to frontend instance hours. I have to think that once python 2.7 is live and concurrent users != concurrent frontends, this will get waaay more reasonable.
you have time before the billing switches on to tune/adjust your application. check out the FAQ and tuning tips page. the prices are going up, but they are also changing, in that we're measuring things differently. most apps that are initially seeing a large multiplier are because of the latter effect, not the former. this is why we built and launched the side-by-side billing. (i'm on the GAE team)
Out of curiosity, have you received any positive responses to the new pricing structure? When it was first announced, it was couched as something users were asking for (unbelievably) but I can count on one hand since that announcement I've seen comments that ran in favor of this.
For the kinds of multiples in increases being talked about, I'm hoping GAE also brings online some professional support people with a 24-hour turn around time. The only times we've been upset with GAE was the lousy support-via-web-form (a form with instructions that doesn't seem to address how we should communicate with the GAE team at all) when something wasn't going right on your end that directly cost us revenue.
I think the turn around on a response to our support problem took >2 weeks. It was successfully resolved, but it was an issue such that we were looking at having to essentially start our entire enterprise over from scratch if it wasn't taken care of.
Your "preview" felt a lot like GMail's "beta" did. You had fully released it and were evangelizing it, the only thing you've done now is removed the label and hiked up your pricing by an astounding amount.
Thanks, it's assuring to hear that tuning will likely reduce the price spike. Looking through the most requested handlers on our site, one that serves an embedded widget is currently not using memcache. I'm hoping tuning that handler alone will make a big difference.
Btw, a dashboard showing handlers sorted by average latency would be a big help! I can use appstats to get close to this, but given that the concurrent frontends are the dominant factor in pricing going forward, having it build in would be great.
Could you clarify how much the Python 2.7 multithreading feature would help I/O bound apps keep their instances down? My reasoning is that the instance/hours will roughly equal current CPU hours (rather than be the 4x, 10x and 100x we're seeing here), but do you have any actual data?
That would be extremely useful to understand the new pricing scheme better.
"for Python we will not be supporting concurrent requests until Python 2.7 is live"
Could I be guessing right in that this means no concurrancy at all within a given instance - so an instance chewing CPU time an instance blocked waiting for IO to complete are no different in this model.
If I was unable to get the multiplier down so that our ultimate hosting cost is < $200 a month, I'd probably switch. But we have revenue to cover the hosting cost, so then again, it would be a big deal to divert or limited eng resources (me and one other guy) towards a big migration project. I'm guessing our hosting costs would be at least $100 a month anywhere else, and I've grown fond of a lot of the services provided with app engine.
One of my clients, whose app sees a decent amount of traffic, is going to go from $510/month to $2070/month _if_ the 50% frontend discount is applied. After the discount lifts, it looks closer to $3300/month.
Which, in my opinion, is insane.
It's not clear to me, yet, what impact the new 2.7 concurrency features will have.
Without performance tuning, this will take my SharedCount API (http://sharedcount.com) from ~$0.50/month to $750 per month, post discount. Unless I can tune it significantly, I'll almost certainly have to shut the API down.
I am assuming (big, unfounded, no-data assumption here) that, with multithreading, instance-hours will roughly match CPU hours for most applications. Most apps take care to minimize actual request CPU usage, so most is in the API.
With the new changes, API time doesn't count, so all you're left with is pure CPU time. Since a single instance can service one request while waiting for another's API to return, you're pretty much limited by the CPU time you use.