[bhauer]

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 this demonstration is impressive!

That said, the requests per second number is not especially impressive given that a modest single server can easily saturate gigabit Ethernet with 100-byte responses (and it's even easier to do so with larger responses) [2]. I am left wondering, does the $10 cost cover the cost of server instances and bandwidth? If so, that is a very good deal. The bandwidth charges for exceeding the capacity of a gigabit Ethernet connection (1M RPS with even the most trivial requests requires more than 1 gigabit) would be substantial with many hosting providers.

[1] https://gist.github.com/voellm/1370e09f7f394e3be724

[2] http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...

[rallison]

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.

[scoot]

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.

[p3rfguy]

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

[simplemath]

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!

[snrip]

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 :)"

[p3rfguy]

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

[jsnell]

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.

[p3rfguy]

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