Hacker News Reader

Comment by scoot | Hacker News Reader

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 down vote from the google up voters)

View on HN

Have you worked extensively with ELBs? They need pre-warming in advance of significant traffic changes, they can't handle spikes well because they take many minutes to respond to changes in traffic volume, and they use an ever-changing set of IP addresses for your load balancer nodes.

The GCE load balancer has none of these problems, which makes it a huge advantage over AWS and ELBs.

Disclaimer: I'm an engineer at Heroku. We manage dozens of ELBs for ourselves, and thousands of them for our customers.

>They need pre-warming in advance of significant traffic changes

Why?

Because they consist of a set of EC2 instances, the vertical and horizontal scale of which is determined automatically based on the average traffic profile of each node. Once the traffic has increased enough to warrant a scaling event, it takes minutes for new ELB nodes to come online and go into DNS rotation before they can start serving traffic.

It's obnoxious that AWS hasn't developed an API call or web interface option for the ELBs to pre-warm them yourself, vs having to contact AWS support to get the pre-warming done "manually".

Out of interest, what is a rough idea of the total requests per second on heroku for everything? All your nodes or whatever you call them? Dynamos?

Is 1,000,000 request per second a stupid, pointless number as no-one ever gets 1,000,000 requests per second or is this some sort of meaningful number?

I can't release any of our traffic numbers, but I can tell you that 1M req/s is an enormous number. For some context, here's a post from Netflix from the end of 2011 where they state that their API received 20,000 req/s at peak: http://techblog.netflix.com/2011/12/making-netflix-api-more-...

Yes, but! The impression I get from this 1 million req/s test is that no actual logic is happening on the backend. E.g. no database queries, no business logic, etc - basically a noop call.

As we saw when running the techempower benchmarks, simply going from the plaintext test to the single database query dropped the best performer from ~600,000 req/s to ~100,000 req/s. Throw in a bit more business logic, another query, and a slightly heavier response, and it is easy to imagine that 1 million req/s now sitting much nearer to 20,000 req/s.

My point being that, that 1 million req/s is a very optimistic number when used in such a comparison. Is it still an impressive max throughput? Yes. I just don't want anyone to think that they can now, say, host 50 netflixes on this setup.

Note: I realize you probably weren't meaning to directly compare those two numbers, but it somewhat read that way. I definitely do appreciate the context though - quite interesting to know that the netflix API was peaking at ~20,000 req/s in 2011.

This is not the point of the test, the test is about showing you that the load balancer in GCE can handle that many requests per second and with a single IP address. Whatever the machines are doing behind doesn't matter since the load balancer job is to handle a ton of traffic. This is practically the only case in which responding with 1 byte makes sense in the test.

I completely get that. I responded to the parent because he introduced the 20,000 req/s number as a comparison point.

The Google test is both a theoretical max throughput (that one wouldn't reach under basically any normal use case) and a test of the load balancer capabilities. The Netflix 20,000 req/s number is, instead, a real use case example.

My point was that one shouldn't directly compare those numbers and say, for example, that this GCE setup has 50x better throughput than Netflix.

I imagine that if Netflix were to stub all of their API calls with noops that returned 1 byte responses, they would be able to handle significantly more than 20,000 req/s. Basically, I don't think we actually disagree here.

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.

Anything that can process 1MM req/sec gets upvotes from me.

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

Not sure what the point you think you are making is here, but the Eurovision site was tested to 50,000 req/sec[1]. 50000 * 20 = 1MM

[1] http://googlecloudplatform.blogspot.com.au/2013/05/how-scalr...

I don't know man, someone's codepen with some pretty CSS is pretty high on the front page with 10 pts and 0 comments.

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

To add a bit of context to Anthony's post here (I'm the guy who wrote the blog post on the Eurovision).

GCE Load Balancing uses a single IP address, you can point your DNS there and forget about it.

What Anthony's post shows is that this IP address will be able to serve 1 (upwards?) of 1 million requests per second.

This matters because you have control over scaling your backend (design properly, add more instances), whereas you don't have full control over scaling your frontend.

Indeed, a problem we had during Eurovision was that mobile providers (it was a mobile app) would cache the IPs of our frontend Nginx servers, so scaling those wasn't as easy.

So this new GCLB essentially "solves" scaling your frontend. That's something I'd care about ;)

Hope this helps shed some light here!

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

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.

Reply on news.ycombinator.com