Live data from Hacker News

Google Shows How To Scale Apps From Zero To One Million RPS, For $10

forbes.com

61–70 of 70 posts

Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10

#61
post #5

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.

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

#63
post #40
post #23

Earlier 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 wish there were more posts here on HN where the OP linked items such as yours, but alas, clickbait rules apply.

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

#64
post #19

Earlier 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.

A fair point, but the scaling granularity advantage is a powerful cost win nonetheless

Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10

#65
The big thing they're crowing about is because you can spin something like this up quickly on demand in the G cloud.

Most 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

#66
post #40
post #23

Earlier 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 saw you dropped this line in the comments under the article. Guess this would be a better place for it :)

"PS... Cloud Performance is hiring :)"

Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10

#67
post #41
post #5

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…

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

DNS load balancing isn't all bad. Google uses it to host www.google.com for example ;)

Re: Google Shows How To Scale Apps From Zero To One Million RPS, For $10

#68
post #61

Earlier 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.

I found it interesting and I upvoted the article. So just because you don't like the company that the article is published by does not mean the article is a marketing puff piece.

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…

I don't think $16,000 a month is really that bad if you factor in what type of money a consistent 1 million reqs/sec would probably give you.

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

#70
post #48
post #25

Earlier 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).

Can you explain this a bit more? Specifically what async type tasks can you not perform?
Post reply on HN