5 ms·

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 al

by psm 15y ago

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)

krosaen 15y ago
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.
davepeck 15y ago
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?
StavrosK 15y ago
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.
- dspillett 15y ago
  "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.
  - sergeys 15y ago
    Correct.
bane 15y ago
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.
buff-a 15y ago
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?
- deleted 15y ago
  [deleted]
mtogo 15y ago
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.
DennisP 15y ago
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/BuildingScalableComplexApps.html 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?

by psm 15y ago

krosaen 15y ago

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.

davepeck 15y ago

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?

StavrosK 15y ago

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.

dspillett 15y ago
"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.
- sergeys 15y ago
  Correct.

bane 15y ago

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.

buff-a 15y ago

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?

deleted 15y ago
[deleted]

mtogo 15y ago

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.

DennisP 15y ago

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/BuildingScalableComplexApps.html 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?