Rudimentary New Pricing Analysis
Ugorji Nwoke
Barry Hunter
--
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.
Barry Hunter
Andrei
AWS
Since you are also learning more with AWS it's better for resume
On May 29, 8:06 pm, Ugorji <ugo...@gmail.com> wrote:
> The other threads don't address this in isolation. I'm hoping Greg can
> address this in his updated document.
>
> GAE Frontend: 128MB RAM, 1.2 GHz processor ... cost 0.08cents/IH
> GAE Backend: 256MB RAM, 1.2 GHz processor ... costs 0.16cents/IH
>
> ~2.4GHz).
> --> COST: 0.02cents/IH
> --> SUMMARY: GAE costs 4X on front end with 1/4 RAM, and 8X on backend, with
> 1/2 RAM
> 1and1 DEDICATED server: 2 X 2.2 GHz CPU, 2GB RAM.
> --> COST: $60/month (roughly 0.08cents/IH)
> --> SUMMARY: GAE provides 1/8 RAM and 1/4 CPU for equal pricing
>
> aggressively that they are not even close to being competitive against other
> established players (like Amazon). It feels atypical of what we would expect
> from Google.
>
> ** Note that this comparison is just for the hosting prices. This is fair
> since the APIs are charged separately (so are not compared here).
>
kwellman
aws.amazon.com/elasticbeanstalk/) and looking forward to the day they
roll out the Python version. With Beanstalk it seems Amazon is moving
towards providing some of the auto-scaling functionality we've become
accustomed to on GAE (and at no additional cost). It would certainly
make the transition easier if it ever comes to that.
Also EC2 does have a free usage tier for new customers.
On May 29, 8:27 pm, Barry Hunter <barrybhun...@gmail.com> wrote:
> For what it worth, I dont think it fair to compare a GAE instance like for
> like to a VPS.
>
> they are very different 'beasts'. GAE in theory provides you much more.
> Google handle all the setup, configuration, provisioning, load balancing.
>
> Granted it does seem expensive, if you only using equivient of one VPS. But
> once you start need to manage multiple VPSs, provision load-balancers,
> re-provision in case of failure etc, make backups. All that happens
> 'magicically' with GAE.
>
> Dont forget you also get a free quota of instance hours too.
>
> On 30 May 2011 01:06, Ugorji <ugo...@gmail.com> wrote:
>
>
>
>
>
>
>
> > The other threads don't address this in isolation. I'm hoping Greg can
> > address this in his updated document.
>
> > GAE Frontend: 128MB RAM, 1.2 GHz processor ... cost 0.08cents/IH
> > GAE Backend: 256MB RAM, 1.2 GHz processor ... costs 0.16cents/IH
>
> > ~2.4GHz).
> > --> COST: 0.02cents/IH
> > --> SUMMARY: GAE costs 4X on front end with 1/4 RAM, and 8X on backend,
> > with 1/2 RAM
> > 1and1 DEDICATED server: 2 X 2.2 GHz CPU, 2GB RAM.
> > --> COST: $60/month (roughly 0.08cents/IH)
> > --> SUMMARY: GAE provides 1/8 RAM and 1/4 CPU for equal pricing
>
> > aggressively that they are not even close to being competitive against other
> > established players (like Amazon). It feels atypical of what we would expect
> > from Google.
>
> > ** Note that this comparison is just for the hosting prices. This is fair
> > since the APIs are charged separately (so are not compared here).
>
Ugorji Nwoke
Barry Hunter
Ugorji Nwoke
roberto.cr
It's a hard choice, you really have to analyze per case.
If only it got cheaper, it'd be a lot more suited to a wider range of
projects.
I could bet this factor isn't present in google's price analysis,
while it definitely should.
If we, as app engine developers who enjoy the system, start to think
about pricing every now and then... something's not right.
* Here's hope for anyone from the app engine team to read this humble
opinion from a fellow GTUG member and app engine enthusiast! *
Raymond C.
Denis Volokhovskiy
request at a
time."
It is not true for JVM application instance - it handles requests
concurrently.
Besides, GAE memcache is globally visible to all instances, but in AWS
you need to setup your own per instance or 3rd party thru REST.
If you have 8 instances up, then you'll have to have 8x more memory
for your
caching - separate record for each instance.
Plus, with global cache, you may store temporary flags/signals/locks
etc.
Memcache requests will be faster inside GAE than to 3rd party.
On May 31, 9:10 am, "Raymond C." <windz...@gmail.com> wrote:
> By "GAE provides you much more", you mean much more *limitation* right?
Andrei
How do you know gae memcache is not part of 128 Mb?
May be it is
How do you know how much memcahce is available to your app, is it
documented?
If you look at http://code.google.com/p/memcached/wiki/NewOverview,
which is one alternative for aws,
you do not need to replicate cache across all instances
If you look at large aws instance it has 7.5 Gb of memory, 4
processors and 850 Gb of space for 34 cents
Even if you take .5 Gb for memcache, which is more than enough you
still have 7Gb of RAM left
http://aws.amazon.com/ec2/instance-types/
On May 31, 3:03 am, Denis Volokhovskiy <altitudebre...@gmail.com>
wrote:
Stefan Podkowinski
I'd very much like to see how much requests GAE (I'm using python) would be able to handle after the scheduler changes compared to a $60 dedicated system say running a node.js + mongoDB + memcache stack. If you'd need to scale out such a dedicated system, my guess is it would financially ruin you to do this with GAE if you have profitable business model behind it.
Robert Kluin
compare the cost of front-ends to most other things. Yes, a dedicated
machine / VPS can handle more requests per second and doesn't impose
many of the restrictions faced on GAE (native code, etc...), but on
GAE there is no OS management overhead, no "low-level" software stack
management, *and* GAE front-ends can scale up/down with demand *plus*
they can be moved to a different data center when needed. That last
points are the important ones. Look at the AWS outage, how much is it
going to increase your costs and complexity to be able to handle those
types of outages? It is included in the price of GAE. There is no
way to know how bad it will hurt until we see how the adjustments they
make to the system, specifically the scheduler, impact apps.
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
Ugorji Nwoke
Jeff Schnitzer
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
Robert Kluin
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.
Ugorji Nwoke
Jeff Schnitzer
particularly impact the proposed pricing changes... these are the same
limitations we have to live with today.
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