I think we're missing a big part of this... How many users were using it?
More than 100,000: http://goo.gl/wiDj6
Google App Engine Pricing Angers Developers, Kills PlusFeed
141–148 of 148 posts
Re: Google App Engine Pricing Angers Developers, Kills PlusFeed
#142Earlier quoted context omitted.
Denormalize. Match your data rows to your access pattern (i.e. your UI). Naive example: if you have a webpage that displays a list of employees, and it must have their department name and boss in that list, you put that data in the employee row. What is the probability that a boss will change his or her name causing you to have update a ton of records? Very low. (not zero mind you, so you have to be able to do it). S…
What is the probability that a boss will change his or her name That's obviously an example of something that will practically never happen, which is why it doesn't work all that well as a justification for ditching SQL databases altogether. I've never used NoSQL for anything, so there must be a lot that I'm missing, and that's why I asked. But it seems to me like you'd be digging up necessary information through qui…
>> What is the probability that a boss will change his or her name
> That's obviously an example of something that will practically never happen
Women changing their name when they get married? A tiny assumption like that can make our software brittle. Now every model that caches the old name needs updating and you need to make sure there aren't any overlapping saves in any of those models that'll overwrite any items in your bulk update. If a single linked model has the wrong old-name cached, your data update process is buggy.
Re: Google App Engine Pricing Angers Developers, Kills PlusFeed
#143Earlier quoted context omitted.
On the contrary, its the SQL database thats "digging up the necessary information through quite a few steps" it just that massive effort required by the SQL server is hidden from you, the programmer, by a one line bit of text called a SQL statement. So you do it all the time . Indeed we've been taught that denormalizing is the "proper" thing to do because otherwise "Bugs happen and referential constraints go a long w…
Yes, an SQL DB does the digging for you, but with NoSQL you'll be doing it yourself, right? Your app will most likely have some kind of "entities", and then records to represent them. How much information can and should you cram into records of various "types"? How much information do you typically end up duplicating across all those "entity records", and is it not a problem?
As I said in my original complaint: I, and many others, spent a lot of time figuring out how to write apps that do it the "app engine way"
That included learning NoSQL. At least that part was not a waste. There are no right answers to your questions, there are only right actions, starting with stepping outside the SQL box and writing an app using NoSQL. I started by thinking of a simple app that would be useful to me personally. I knew java servlets, I knew SQL, I knew all sorts of things, but after several iterations my app is architected like no app/server I've ever written before. Almost every iteration involved starting doing it the way I knew how, running into either roadblocks or major cognitive dissonance, and then rewriting it to fit these new-fangled constraints. Its been a huge learning experience. You might like to try it.
Re: Google App Engine Pricing Angers Developers, Kills PlusFeed
#144Hi folks, I'm on the App Engine team, and I just wanted to clarify one thing: The main difference between CPU hours and Instance hours is that CPU hours are charged based on CPU usage, while instance hours are based on wallclock time. The high ratio between the two you can see with PlusFeed is because it's spending a lot of time to serve each request, most of which is spent doing nothing - likely because it's doing o…
First of all, thank you for chiming in, here, on HN. Your presence might also be welcomed on the google forum, since I've read most of the posts there and no one has managed to answer this question. If memory pressure is the issue, how are the trusted testers finding their memory pressure when they have a whole number of in-flight requests? If the PlusFeed fellow got 2.7 working, we'd expect to see 100/3.5%= 28 in-fl…
That's a good question. I can't point to published figures, since the 2.7 runtime is still fairly new, but I can say that based on both my personal experience and based on fairly basic reasoning, the per-thread memory overhead is definitely a lot less than what's required by the whole instance. The entire of the Python standard library, along with your framework and other libraries, are shared overhead between all the threads.
The issue with charging by CPU hour was that you could occupy memory-seconds as much as you wanted without charge; that's no longer the case - by charging for instances, we're implicitly charging for the memory they use.
As far as determining how many instances you run - you can do this to a large degree, both by setting budget limits, and by setting scheduler parameters.
Re: Google App Engine Pricing Angers Developers, Kills PlusFeed
#145I also have an app on GAE. http://www.tubesmix.com
Right now there's no charge as there's only a couple hundred users and the resources used are low.
But this change worries me a lot. Even more so since all my backend code is tied to GAE infrastructure. This is very disappointing coming from Google. Since when did they become so nickel-and-dimey?!
Re: Google App Engine Pricing Angers Developers, Kills PlusFeed
#146Earlier quoted context omitted.
Google historically splits off their "front end" which is dealing with messages from the internet and their "back end" which is processing what those messages want to do. It was briefly described in the original search paper they presented. Of necessity, most machines that Google runs have 'private' (as in not directly addressable) addresses. This is how it seems that everyone runs things when they get above a certai…
Not trying to piss all over this, since I thought you might have been saying something I didn't know. But I have worked at Google for a long time and basically everything you wrote is incorrect and has been since at least 2005 before App Engine even existed (why would a paper written in 1998 be relevant?). Without going into too much detail, it shouldn't surprise anyone that physical machines are interchangeable via…
The original point is "almost right". The scarce resource reflected in the new pricing model is not machines, but RAM. The old pricing model assumed CPU time was the essential resource. The new pricing model bills you for the amount of time your instance (which has a fixed RAM reservation) stays resident.
Re: Google App Engine Pricing Angers Developers, Kills PlusFeed
#147Earlier quoted context omitted.
Yes, an SQL DB does the digging for you, but with NoSQL you'll be doing it yourself, right? Your app will most likely have some kind of "entities", and then records to represent them. How much information can and should you cram into records of various "types"? How much information do you typically end up duplicating across all those "entity records", and is it not a problem?
As I said in my original complaint: I, and many others, spent a lot of time figuring out how to write apps that do it the "app engine way" That included learning NoSQL. At least that part was not a waste. There are no right answers to your questions, there are only right actions, starting with stepping outside the SQL box and writing an app using NoSQL. I started by thinking of a simple app that would be useful to me…
I will end up using NoSQL sooner or later, of course. But now I'm just curious about whether there's a Right Way to do things.
Could you just give me a brief description of how you arrange things (like "entities") with NoSQL?
Re: Google App Engine Pricing Angers Developers, Kills PlusFeed
#148Earlier quoted context omitted.
What is the probability that a boss will change his or her name That's obviously an example of something that will practically never happen, which is why it doesn't work all that well as a justification for ditching SQL databases altogether. I've never used NoSQL for anything, so there must be a lot that I'm missing, and that's why I asked. But it seems to me like you'd be digging up necessary information through qui…
>> What is the probability that a boss will change his or her name > That's obviously an example of something that will practically never happen Women changing their name when they get married? A tiny assumption like that can make our software brittle. Now every model that caches the old name needs updating and you need to make sure there aren't any overlapping saves in any of those models that'll overwrite any items…
Now every model that caches the old name needs updating and you need to make sure there aren't any overlapping saves in any of those models that'll overwrite any items in your bulk update. If a single linked model has the wrong old-name cached, your data update process is buggy.
Well, that sounds like the kind of stuff I'd like the other guy to talk about. How does he avoid the bad sides of having all your data in a key - value store?
How would/do you?