--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
That said, I also wonder how friendly this new pricing is going to be
for small and very large apps. I'm sure there will be several classes
of applications that will need to reevaluate hosting options.
When comparing prices, don't underestimate the value of the HR
datastore, scalable front-ends, memcache, *and* the management costs
of those things. I've managed geographically distributed databases,
if you've not done it -- it is significantly more involved than you
think (assuming you care about your data). Don't forget to factor in
the cost of that management into your comparisons; if things run very
smoothly it will still be several thousand dollars per year.
Robert
I don't think the amount of RAM supplied to a frontend instance is
particularly relevant - in most web architectures, frontend instances
just shuttle data back and forth between the user and backend data
services (datastore, memcache, facebook, etc). So it's really hard to
compare $/MB figures between Appengine and, say, EC2.
A better measure for frontend instances is $ per request throughput.
For each dollar spent on frontend instances, how many requests can you
serve? It's certainly going to be a major issue with single-threaded
python, especially if you make urlfetches to latent services. On the
other hand, if GAE's Java servers achieve the same levels of
concurrency that standard Java appservers achieve, then the limit will
be CPU power - and, to my knowledge, nobody has made any comparative
$/CPU measurements with GAE.
On the other hand, $/MB is a perfectly useful way of measuring GAE
*backends* since RAM is often the primary constraint of a backend
service. For many applications, comparing GAE backends to Other Cloud
backends is apples-to-apples comparison, and GAE's value is
extraordinarily poor.
I also totally agree with your point about excluding datastore pricing
from this comparison, since it is charged separately (as is Amazon's
SimpleDB). However, we need to start looking in greater detail at the
pricing of datastore operations, because it sounds like this may also
be a very significant price hike, and possibly will affect people much
more than the instance pricing that everyone has been talking about.
Jeff
On Tue, May 31, 2011 at 14:18, Jeff Schnitzer <je...@infohazard.org> wrote:
> Some thoughts on your comments:
>
> I don't think the amount of RAM supplied to a frontend instance is
> particularly relevant - in most web architectures, frontend instances
> just shuttle data back and forth between the user and backend data
> services (datastore, memcache, facebook, etc). So it's really hard to
> compare $/MB figures between Appengine and, say, EC2.
>
> A better measure for frontend instances is $ per request throughput.
> For each dollar spent on frontend instances, how many requests can you
> serve? It's certainly going to be a major issue with single-threaded
> python, especially if you make urlfetches to latent services. On the
> other hand, if GAE's Java servers achieve the same levels of
> concurrency that standard Java appservers achieve, then the limit will
> be CPU power - and, to my knowledge, nobody has made any comparative
> $/CPU measurements with GAE.
I've thought about $/request throughput too, particularly since I use Python....
>
> On the other hand, $/MB is a perfectly useful way of measuring GAE
> *backends* since RAM is often the primary constraint of a backend
> service. For many applications, comparing GAE backends to Other Cloud
> backends is apples-to-apples comparison, and GAE's value is
> extraordinarily poor.
>
> I also totally agree with your point about excluding datastore pricing
> from this comparison, since it is charged separately (as is Amazon's
> SimpleDB). However, we need to start looking in greater detail at the
> pricing of datastore operations, because it sounds like this may also
> be a very significant price hike, and possibly will affect people much
> more than the instance pricing that everyone has been talking about.
Excluding datastore pricing is a fair point. I also think defining
datastore pricing is important. From a discussion with Greg (last IRC
office hours), it sounded like the new pricing is going to be
somewhere around 25% above the current HR datastore pricing.
Honestly, that is not as bad as I first thought it was going to be.
Of course for master-slave apps it is going to be very noticeable.
FWIW, Similarity does frequently load 50+ entities at a time (say, one
set of match results) each of which is a hefty structure that could
theoretically be up to the 1M limit in size... but in practice,
they're not likely to be more than a couple K. The chance of blowing
the heap is finite but very, very low. You're absolutely right,
memory consumption goes up with concurrency, and the multithreading
option is new, and the scheduler is still being tuned... this is just
something to keep an eye on.
Jeff