Hacker News Reader

Comment by psm | Hacker News Reader

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)

View on HN

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.

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

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?

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.

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?

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?

Reply on news.ycombinator.com