I’m not worried about the minimum price so much as I am the 8 cents per instance hour. Rackspace cloud gives you a significantly more powerful instance for 11 cents an hour, and most of my CPU hours were billed by the API not by the Instance. So I’m not sure how my model just changed.
All of my apps that were running at $40 a month are at least 3 instances 24x7 and most are well above that… From what I can tell, I’m going from $1.40 a day. To 60*24*.05 = $72 a day. Plus 98 cents for bandwidth. So $73 a day. That’s a change from $45 a month to $2,100 a month.
If this is the case, I’m out. We had expected things to go up 25-50% not 500%
--
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.
I’m going to hold you to that… I know where you work, and I’m not beyond sitting in front of the door every day with a sign that says “Gregory D'alesandre promised to only increase my price 2.5x not 70x” and people will say “really? He’d be happy with knowing his cost went up 2.5x? That man is a loon”
Only likely not being from Canada or Michigan they wouldn’t use the word loon.
-----Original Message-----
From: google-a...@googlegroups.com
[mailto:google-a...@googlegroups.com] On Behalf Of Sylvain
Sent: Tuesday, May 10, 2011 3:25 PM
To: Google App Engine
Subject: [google-appengine] Re: Is App Engine suddenly becoming more
expensive???
--
This could be fixed by restoring the 2000 email quota for emails sent
to admins of the app, and bumping up the price of the first X emails
sent to non-admins, with a bulk discount for further usage.
> $9 = cost of a dream host account...
Dreamhost gives you storage, bandwidth, memory etc for $9. On App
Engine $9 will buy you the opportunity to be further charged for
actual usage. It's a regressive tax on startup projects, which
considering the effort made to offer a completely free tier, is self
defeating.
Go is currently single-threaded, but this too is something that could change over time.Greg
In the future if Google's scheduler is not optimal, you will be
charged for it. What is the incentive to get it right? How will you
know it is right?
Here's another perverse incentive: under the current scheme memory
usage is used as an input to the scheduler as well as latency and
start-up time. Apps which use less memory can have more instances at
the same resource cost to Google. My incentive is to optimise memory
usage. Under the upcoming scheme you are charged per-instance, so
there is zero incentive to optimise memory usage.
For once, it now seems that Java has an advantage, as Python (and GO) users do not have the option of using multi-threaded to reduce the number of instances. So although Python (and GO) will *potentially use less resources and a lower footprint, will they now get charged more due to a limitation in the app engine runtime?
Also, although goroutines and channels are present, when a Go app runs on App Engine only one thread is run in a given instance. That is, all goroutines run in a single operating system thread, so there is no CPU parallelism available for a given client request. We expect this restriction will be lifted at some point.
Even though $9/month is pretty insignificant to many of us because1. It is a fixed cost2. It is smallWe still should not gloss over it. Like Stephen said, this is really just a tax for the privilege of using blob-store and other billing-enabled services.
Having said that, I reckon that this is Google's attempt to streamline their business package (which they are doing away with) by saying that anyone that needs higher level services will pay a per-app or per-account cost. In that light, it becomes more palatable (as it simplifies the offering), and I for one am okay with that.I think the bigger concern is the per-instance cost. This is especially troubling for1. folks that depend on the always-on features in java.
2. folks in Python or the new GO runtime that don't as yet have concurrent request support. More instances will be spun dynamically with a consequential cost to them which is expected to be significant).
Hopefully, the new scheduler will iron out a lot of these unknowns so we're back to being happy app-engine users. Right now, it seems we're the only ones in the whole Google Ecosystem that's unhappy with some of the recent announcements.Actually, scratch that - I'm very happy for 2 things:- GO language runtime support (the geek in me is just thrilled)- Moving away from Preview status (I was always concerned about the life of GAE beyond the promised 3 years support post EOL. This removes my fears).
Hi Stephen,I am totally with you on it. I actually alluded to this earlier, when I said:For once, it now seems that Java has an advantage, as Python (and GO) users do not have the option of using multi-threaded to reduce the number of instances. So although Python (and GO) will *potentially use less resources and a lower footprint, will they now get charged more due to a limitation in the app engine runtime?In building my app, I spent a lot of time optimizing resource usage, et al. With this model, all that seems to be for naught.Somewhere in the docs today, there's a note to the effect that "apps on the java runtime will be charged more for using using more resources".
I don't understand how this will be ironed out, which is why I termed this all unknowns. From what Greg says, it sounds like there's still some stuff to be ironed out on Google's end, and we'd only really know how things shake out once we see how the new scheduler works.I'm holding my breath ...P.S. Google has been pretty fair and upfront with app engine - I haven't had a reason to distrust them yet. I'm hoping that their promotion of AppEngine from Preview will still maintain this fairness.
I just checked the new proposed pricing here...
http://www.google.com/enterprise/appengine/appengine_pricing.html
I'm confused why all the items below "Channel API" in the API Pricing
models have check marks instead of a price per unit. What does that
mean?
And when they say, "Frontend Instances", does that include instances
handling task queues and crons?
Thanks!
Albert
On May 11, 8:24 am, Ugorji <ugo...@gmail.com> wrote:
> eeIt's actually stated in the blog:http://blog.golang.org/2011/05/go-and-google-app-engine.html
>
> Also, although goroutines and channels are present, when a Go app runs on
> App Engine only one thread is run in a given instance. That is, *all
> goroutines run in a single operating system thread, so there is no CPU
> parallelism* available for a given client request. We expect this
> restriction will be lifted at some point.
>
> So you can still use go routines, channels, etc - but we're back to like the
> days of green threads in java where the runtime multiplexes them on a single
> thread (which is fine). However, we don't get concurrent web requests on the
> same instance (which is not fine). Consequently, right now, Java Runtime
> seems to have a pretty significant advantage over the others (even over GO
> which has concurrency as some of its major advantages). And with instance
> pricing, it seems like it directly affects cost.