The only reason I can see for this being this high on the front-page [18 points and only one comment(from a googler)] is the google employee block vote (apparently tech-savvy isn't a prerequisite in the google upvote marketing department): 1 million requests per second is 20 times greater than the throughput in last year’s Eurovision Song Contest, which served 125 million users in Europe No, r/s != Gb/s.* (Cue the do…
I don't work at Google, but when people say something like "cue the downvotes" or "I know I'm going to get downvoted," I proceed to downvote them because that's an incredibly stupid and meaningless thing to say. In fact, it reeks of arrogant stubbornness ("I don't care about the community, I know I'm right, etc." Knowing you're right is not bad in of itself, it's being arrogant about it that is). So I downvoted you.
Google Shows How To Scale Apps From Zero To One Million RPS, For $10
61–70 of 70 posts
Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10
#62Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10
#63Earlier quoted context omitted.
Couldn't agree more. As I (poorly) tried to point out in my earlier off-the-cuff comment, requests-per-second is a meaningless measure without the context of the size of those requests. The Forbes repost and the original google marketing article are both vague on details, and appear to conflate requests-per-second with throughput.
Marketing Post.. Ouch :) One of the things I love about working at Google is we in engineering are empowered to share our knowledge. For those wanting the details check out the step-by-step instructions in the Gist ( https://gist.github.com/voellm/1370e09f7f394e3be724 ). The goal was to measure the speed of scaling and load balancing vs egress. Bigger egress would not change the load balancing decisions. Anthony F. V…
I think I'm going to play with your script package over the long weekend in our dev cluster - Thanks! And nice work!
Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10
#64Earlier quoted context omitted.
GCE instances are charged in 1 min increments ( https://cloud.google.com/pricing/compute-engine ), not 1 hour increments like AWS ( http://aws.amazon.com/ec2/pricing/ ). 1 min increment billing enables you to spin up massive Web clusters to handle spikes or Hadoop clusters so big that you can process the entire dataset it a few minutes, while paying less than you would for a smaller AWS cluster that's billed by the h…
It's definitely finer-grained, but there's still a 10-minute minimum per instance: billing is only per-minute above 10 minutes. So if you run a massively parallel 2-minute Hadoop job, you pay num_instances x 10min. Admittedly that's still a win, since AWS would bill you for 6x as much instance time. But it's not a 30x differential as you might guess from the headline "hourly" vs. "per-minute" pricing.
Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10
#65Most sites aren't remotely close to this artificial traffic pattern (1 packet request, 1 packet response).
It's kinda cool from an L4 load balancing perspective that it's only one fault tolerant IP address. In terms of L4 LB throughput though, a single box with IPVS will happily do 1M pps.
Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10
#66Earlier quoted context omitted.
Couldn't agree more. As I (poorly) tried to point out in my earlier off-the-cuff comment, requests-per-second is a meaningless measure without the context of the size of those requests. The Forbes repost and the original google marketing article are both vague on details, and appear to conflate requests-per-second with throughput.
Marketing Post.. Ouch :) One of the things I love about working at Google is we in engineering are empowered to share our knowledge. For those wanting the details check out the step-by-step instructions in the Gist ( https://gist.github.com/voellm/1370e09f7f394e3be724 ). The goal was to measure the speed of scaling and load balancing vs egress. Bigger egress would not change the load balancing decisions. Anthony F. V…
"PS... Cloud Performance is hiring :)"
Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10
#67The only reason I can see for this being this high on the front-page [18 points and only one comment(from a googler)] is the google employee block vote (apparently tech-savvy isn't a prerequisite in the google upvote marketing department): 1 million requests per second is 20 times greater than the throughput in last year’s Eurovision Song Contest, which served 125 million users in Europe No, r/s != Gb/s.* (Cue the do…
Throughput is a measure of work over time. So here I was referring to throughput in terms requests per second and not Gb/s. So it was a direct comparison of 1M RPS (Compute Engine Load Balancing) vs 50K RPS (DNS Load Balancing). Anthony F. Voellm Google Cloud Performance Engineering Manager @p3rfguy
Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10
#68Earlier quoted context omitted.
I don't work at Google, but when people say something like "cue the downvotes" or "I know I'm going to get downvoted," I proceed to downvote them because that's an incredibly stupid and meaningless thing to say. In fact, it reeks of arrogant stubbornness ("I don't care about the community, I know I'm right, etc." Knowing you're right is not bad in of itself, it's being arrogant about it that is). So I downvoted you.
Thanks, but I was specifically referring to the same voting ring that appeared to have put the article on the front page in the first place. I would hope the rest of the community would recognise a blogspam repost of a marketing puf-piece puff piece when they see one.
Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10
#69$10 for a 10 minute test, okay. A month of 200 US-hosted n1-standard-1 machines would cost 200 * $.115 * 30 (days) * 24 (hours)... over $16,000. That doesn't include load-balancing, bandwidth, or any additional charges there may be. The price shouldn't be mentioned anywhere in the article. Demand is elastic of course, and if you really want to scale in a cost-effective manner you also need to do auto-scaling. As far…
1m req/s is:
60 million+ reqs an hour
1.4 billion+ reqs a day
43 billion+ reqs a month
It would be a weird situation to be serving that much traffic but not being able to afford hosting.
It would be cool if someone could estimate the cost of what it would take to sustain 1m reqs/s with dedicated hardware or maybe an unmanaged VPS cluster.
Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10
#70Earlier quoted context omitted.
App Engine is not just a place to run your code. It has a nice deployment system with the ability to flip between versions instantly. It provides a few great pieces of core infrastructure: the datastore, task queues, and memcache (there are many others, but those are the essentials). The SDK gives you a stand-alone development server for testing locally. If you want to build web apps (or a backend for mobile apps), A…
I like App-Engine and now that there are open-source, API compatible alternatives, there is no lock-in to worry about either. The biggest drawback for App Engine is lack of async support. The only ways to scale are: multiple-threads (slow) or multiple instances (costly).