Hacker News Reader

Comment by krosaen | Hacker News Reader

A key point seems to be:

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

View on HN

Oh shit, and the $270 a month is with the 50% discount:

"""The Frontend Instance costs reflect a 50% price reduction active until November 20th, 2011. Learn more about the price reduction and ways to reduce your costs permanently."""

So come winter, I'm looking at > $500 a month... here's hoping concurrent requests on the python runtime will make a huge difference, otherwise, sheesh.

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)

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.

Do you have a sense of how much tuning can reduce costs? We're looking at a ~7x jump in prices for a big app; might we be able to quarter that? Halve it?

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.

Correct.

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.

Can you explain how on earth my app goes from 0.02 cpu-hours to 2.8 instance-hours?

Are you doing the "any part of an hour is billed as an hour" thing that EC2/Azure do?

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.

This is a bait-and-switch, plain and simple.

Then I have a question for you, which nobody's answering on the google group.

Google is charging per datastore operation, and last I saw was defining each entity returned as an operation.

If you were building a social network or twitter clone using the techniques they recommend in this talk at GoogleIO: http://www.google.com/events/io/2009/sessions/BuildingScalab...

...you could easily pull back a hundred entities each time you pull someone's feed. Each entry is a separate entity. It'd cost you a buck for every pageview.

Is that an accurate assessment?

At what point will you consider moving to a different provider?

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.

Have you thought about slapping some advertising on that? It's a useful service and I can see it pulling in lots of users.

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.

I hope to be proved right, anyway.

You're also limited by the number of threads the GAE team will decide you can use per instance.

Reply on news.ycombinator.com