Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

forbes.com

Post reply on HN
Print view View original

31–40 of 70 posts

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

#31

Post by thrownaway2424 »

yeukhon wrote: post #12

I am pretty excited and yet shocked to see what Compute Engine has evolved into. The original Compute Engine was about scaling (as cluster) in scientific experiment and yet this news makes me think Compute Engine is becoming the new App Engine but with full control of the VM (plus the amazing autoscaling feature). I always like to control my own VM because I can do much more with a VM than a sandbox (to me an App Eng…

Compute Engine is not for scientific experiments, or at least not specifically. Perhaps you are thinking of Exacycle? http://research.google.com/university/exacycle_program.html

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

#34

Post by bgoldy »

recuter wrote: post #8

I keep checking to see whether or not I can run my own images yet but Google Compute Engine so far supports less things than even Digital Ocean. What if I don't want to run your version(s) of CentOS/Debian, guys? Hmm? (I hope somebody from there reads this) :) Still, its a very very interesting offering and something to keep an eye on. I bet nobody here is using it yet because its still early days and the thread devo…

Stay tuned - Getting custom image support and custom kernels so you can run things like Docker is just around the corner.

-Brian (@bgoldy)

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

#35

Post by rallison »

bhauer wrote: post #20

I only skimmed the gist with the instructions for reproducing the test [1], but in that skimming I could not figure out what the request and response were in this simulation. Were these responses 100 bytes, 1k, 10k, 100k? I guess small responses, but I'm not certain. I know the goal of the test is to demonstrate how capacity can be scaled upward in very little time and with comparatively little effort. And for that t…

Indeed. On a singular i7 machine with a gigabit connection, a number of frameworks are in the 400,000-600,000rps range when returning super trivial responses. In comparison, from the original Google blog post:

To demonstrate scaling of the Compute Engine Load Balancing fanout we used 200 n1-standard-1’s Web Server running Apache v2.2.22 on Debian 7.1 Wheezy Images. Users are encouraged to use larger VM types for better single machine backend web serving, however here we demonstrated the scaling of the load balancer to backends and were not concerned with the backends themselves using every cycle to serve responses. Each backend web server received ~5K requests per second, which is an even distribution.

So, to match the peak rps of solid (but not top of the line) dedicated hardware appears to take upwards of ~120 instances of n1-standard-1 (assuming that it scales linearly, of course). Not a trivial number.

That said, I am impressed at how quickly this can scale up. If you have a site that normally runs fine on a couple of instances, but occasionally sees massive spikes in traffic, this could make sense. And from a purely engineering point of view, GCE and EC2 are quite interesting.

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

#36

Post by argonaut »

scoot wrote: 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.

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

#37

Post by mayanksinghal »

scoot wrote: 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 didn't upvote the submission, I didn't downvote you - but if you call people shills when they are not, some of them might. And I find 1M R/s impressive, but you can ignore it if you think it is trivial.

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

#38

Post by p3rfguy »

bhauer wrote: post #20

I only skimmed the gist with the instructions for reproducing the test [1], but in that skimming I could not figure out what the request and response were in this simulation. Were these responses 100 bytes, 1k, 10k, 100k? I guess small responses, but I'm not certain. I know the goal of the test is to demonstrate how capacity can be scaled upward in very little time and with comparatively little effort. And for that t…

We really wanted to focus on the scale of operations for this article so we used a full http request / response. The payload of the response was 1 byte.

Anthony F. Voellm Google Cloud Performance Engineering Manager @p3rfguy

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

#39

Post by p3rfguy »

jsnell wrote: post #24
bhauer wrote: post #20

I only skimmed the gist with the instructions for reproducing the test [1], but in that skimming I could not figure out what the request and response were in this simulation. Were these responses 100 bytes, 1k, 10k, 100k? I guess small responses, but I'm not certain. I know the goal of the test is to demonstrate how capacity can be scaled upward in very little time and with comparatively little effort. And for that t…

The blog post says 1 byte responses excluding HTTP headers. Since it was a standard Apache configuration, the headers would probably be something like 200-300 bytes.

Thats about right. In hindsight a tcpdump or other trace might have been useful to include.

Anthony F. Voellm Google Cloud Performance Engineering Manager @p3rfguy

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

#40

Post by p3rfguy »

scoot wrote: post #23
bhauer wrote: post #20

I only skimmed the gist with the instructions for reproducing the test [1], but in that skimming I could not figure out what the request and response were in this simulation. Were these responses 100 bytes, 1k, 10k, 100k? I guess small responses, but I'm not certain. I know the goal of the test is to demonstrate how capacity can be scaled upward in very little time and with comparatively little effort. And for that t…

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. Voellm Google Cloud Performance Engineering Manager @p3rfguy

Post reply on HN