Also, the limit isn't 500 requests per second, it's 30,000 requests per minute. So this doesn't kick in until you get 30,000 requests. The App Engine help says this should be sufficient for a Digg or Slashdot link... seems reasonable to me.
I can see it now - I got New York Times coverage (once in a lifetime thing), the new users start hammering the site and I am sending an email to Google begging them to increase the quota. Which they may or may not get by the next week or something.
You know, this just does not look like a good plan for success. Whatever happened to worry-less scale that they promised?
It varies with the emphasis (front page or not) etc., here is some of the latest information I could find on super surges (some people reported over a million viewers):
App engine averages out your quotas over time, so the limiting does kick in before you reach 30,000. It's not 30,000 every minute where once you reach 30,000 you have to wait until the next minute.
This is overblown. Estimate 10 objects per page (if you don't have good cache headers)... 43 million GETs a day (1.3 trillion requests a month) at 10/page is around 4 million pages a day and 130 billion a month. Adjust your estimate as necessary but it's quite a lot of page views...
It's about fast scale-out. If you are getting that kind of sustained traffic, then you can likely pay for the conventional hosting.
The problem is what happens when you have normal trafic but get spikes? The NY Times links to your startup one morning and suddenly you have hundreds of thousands potential new customers kicking the tires at the same time. You'd like to be able to handle that easily, so you can convert some small % into paying customers and take advantage of the free publicity. But if your site goes down in flames you give a bad first impression to all those potential sales, and they will likely never give you another chance.
I agree but still think that's possible with the quota (before you request an increase).
In an eight hour period (the work day), 500 requests per second is enough to serve 1 million people 17 GETs. And the vast majority of people will bounce away after one page view.
So unless you cured cancer or something, I wouldn't worry.
I agree it seems weird the guy has been blogging since 1994 (per his Blogger about page) with a whopping 2 posts, yet somehow ends up here on HN? Kinda fishy... also, isn't Azure the polar opposite of the technology spectrum from AppEngine? I would of expected "EC2 here I come" instead.
Azure and AppEngine are much more closely related than either to EC2.
Both Azure and AppEngine are platform-aware and do the scale-out magic for you; you write your code and they make sure it scales (more or less, I'm certain there's still some application-efficiency/scalability rewriting, but you never worry about individual machines, in theory)
EC2 means machine level administration and custom scale-out/scale-up techniques. Not to mention there are load-balancing concerns when you're in the more-requests-than-a-single-machine-can-handle range, although that's above 500/sec for many applications.
Umm, not to be picky, but can't a single server handle 500 requests a second if (as is likely) most of them are for static content?
I just hit my site's homepage with ab (Apache Benchmark) just for giggles. Its on a 256 MB Slicehost VPS ($20 a month), with a bog-standard install of Nginx serving static content.
Nginx has a maximum of two processes.
Result of smashing it with 25 concurrent requests through AB: served 80 requests a second. I'm guessing I could set that number of child processes higher and watch as it dutifully saturated my outbound link. 500 requests a second is only a factor of six and change, that is probably easily doable.
90% of the workload going into an app engine app is going to be the same stuff, right? Hitting small bits of static content, repeatedly.
Remind me why you need to rearchitecture your entire application if the limits to what The Cloooooooooooud can scale to are in any way comparable to what you can get from a single $20 VPS?
If you are hosting predominantly static content there, then it doesn't make a lot of sense for this level of traffic because your bandwidth bill is going to be sky high (put your static content elsewhere). Also there are uptime properties with the app and its datastore you are not going to get at slicehost without work and other instances.
And besides, this is not a limit on Google's architecture, this is an initial limit they put in place for you to bump up against... which is why I find the guy's argument inflammatory, there is no "hoax" here. EC2 has an initial speedbump too (20 nodes) and they'll bump it up if you ask, our max is at 200 right now.
(btw I'm using slicehost, EC2 etc. myself, and I don't see appengine as some silver bullet. I just don't think this article's argument holds any water)
As both a user of slicehost and google app engine, I wanted to chime in here.
Google's approach for scaling is "do it our way, and you don't have to worry about architecture. You won't have to worry about master/slave nodes in your DB. Mirroring static files on separate app servers. Sharding your database by feature. Using a hardware load balancer router, etc."
It is the instant coffee of scalable web apps. Just add hot water and enjoy.
Slicehost, on the other hand, is the other end of the spectrum. You're roasting your own beans, grinding them up, boiling your own water, and so on. You get total control, but you have to know what you're doing and be comfortable with it.
As an aside, its been pretty well documented that a small team of good developers can scale a web app very quickly, but Google's aiming more for the hobbyist market: Its trying to entice a single average developer to write a web app that will scale very quickly.
And for the record, I don't see AppEngine as some kind of magic bullet either. But if I was a full-time CS student in my freshmen/sophomore year, and I was told (learn rails/apache/passenger/EC2/MYSQL/sharding/etc) vs. learn python and appEngine) I know which way I'd go. Its easy infrastructure with a low barriers to entry -- both in development and financial cost.
(Lastly: Not trying to start a flame war over what's better. I'm simply trying to state a point that AppEngine may have more "hobbyist" appeal.)
I was thinking about monthly traffic here and how expensive these services turn out to be (based on my memory of conversations in the past) but for these surges plus "normal" web pages this doesn't seem like as big of a deal as I made it out to be.
Say that "it" happens and you get a million viewers in one day. Say you have a few pictures and assets that adds up to 200K and we're just dealing with one view (like a blog entry or article).
On AppEngine, it looks like this adds up to $20 for 1 million downloads of 200K and if you host static stuff off S3 (to essentially eliminate any worry at all about the 500 requests/second initial limit while still having "no server maintenance") it will be $34.
Even for dynamic content, VPS can push through stuff. I can hit a page that's generated dynamically at about 170 requests per second. On my $30 a month VPS. For a page requiring database access, I can run about 40 per second... with the DB running on the same VPS.
jjx here (The original poster). My blog post is accurate. Read the description of scalability that Google provides. It implies that you can scale to any degree. 500 request a second is an absolute joke. I can use any web development environment (like Rails), and get 500 requests per second on a crappy little machine. So App Engine doesn't scale, at all.
The main reason I wrote this post is out of utter frustration with Google. They should get out of the developer tools business. For months I have been coding around their onerous and ridiculous quotas, waiting for the nirvana of paid quotas, only to be horrified by the new quotas. If these quotas are not lifted, then I've completely wasted my time. As it stands now, I'm abandoning App Engine.
I read that and it seems like the person is talking about not getting a special free quota he had and that he was in negotiations for (but had not heard back yet)?
That seems like a completely different situation to me than a paying customer who wants to increase their quota.
Note that this translates to "give Google more money" so I don't know why you think this is something like begging.
On Amazon, they also want to make money and they happily increase quotas. They just want to know what's up, if you're a legitimate customer who's really going to pay them and not do a chargeback on the credit card the first month, etc.
@jjx, you should have known better than investing your resources into a platform that does not suit your needs. When buying a product buy it for it is today, no what it may or may not become tomorrow.
Gotta agree that 500 req/s for a scale on demand service. I'm building my service on the Azure platform, though nothing has been officially announced, it doesn't look like they'll have similar limits.
Bottom barrel shared hosting companies like www.myhosting.com and www.dreamhost.com top out at about 50/requests/second. Compared to that, 30,000 reqs/sec seems reasonable enough to me.
The promise of the cloud was a goodbye to limits. Deploy to the cloud, and you'll never run out of anything. Ever.
Amazon (, promise of): We add resources faster than you can use them, kthxbye.
Google apps: Hit the once-in-a-lifetime really, really big one, and we'll be serving up 503's to your customers instead of writing invoices to you. Oh, and if it's sustained we might need you to spend critical time re-deploying to a different architecture.
The difference between the two is that Amazon isn't free. Its pay-per-use.
Provided that you stay within the "free" quota, an AppEngine app can be developed/deployed for free.
One is more "hobbyist" than the other. S3/EC2 is used all over the place by professionals, whereas AppEngine has yet to to really achieve that same kind of ubiquity (in terms of developer mindshare).
That is what you get for building your project on a proprietary platform. You are giving control to a third party and you better have a plan how to deal with the associated risk.
Along these lines, it strikes me as odd how people that would want to run open-source software on their own computers are completely content with running closed web applications where they have no freedom and no control at all. It may be the same reason people are willing to pay for bottled tap-water: convenience - it seems to trump other factors (including ethics and morality) by far.
jjx here. This is not propaganda, nor is it incendiary. It's the truth. I have been promoting App Engine to everyone I talk to, because of the ease of deployment and the promise of scalability. I have been waiting for months for the beta quotas to be lifted. My wait has been in vain. It seems that scalability to Google means it will scale on one little machine in their infrastructure. If 500 requests per second is the best I can get from "10 years of knowledge Google has in running massively scalable, performance driven systems", then the hype of Google is a fiction.
http://code.google.com/support/bin/request.py?contact_type=A...
Also, the limit isn't 500 requests per second, it's 30,000 requests per minute. So this doesn't kick in until you get 30,000 requests. The App Engine help says this should be sufficient for a Digg or Slashdot link... seems reasonable to me.