In the same vein, I was curious to compare the max responses/second on dedicated hardware vs ec2 on a per framework basis. The following is percentage throughput of ec2 vs dedicated (in res/s):
cake 18.9% (312 vs 59)
compojure 12.1% (108588 vs 13135)
django 16.8% (6879 vs 1156)
express 16.9% (42867 vs 7258)
gemini 12.5% (202727 vs 25264)
go 13.3% (100948 vs 13472)
grails 7.1% (28995 vs 2045)
netty 18% (203970 vs 36717)
nodejs 15.6% (67491 vs 10541)
php 11.6% (43397 vs 5054)
play 20.6% (25164 vs 5181)
rack-jruby 15.6% (27874 vs 4336)
rack-ruby 22.7% (9513 vs 2164)
rails-jruby 22.7% (3841 vs 871)
rails-ruby 20.7% (3324 vs 687)
servlet 13.4% (213322 vs 28745)
sinatra-jruby 21.2% (3261 vs 692)
sinatra-ruby 22.2% (6619 vs 1469)
spring 7.1% (54679 vs 3874)
tapestry 5.2% (75002 vs 3901)
vertx 22.3% (125711 vs 28012)
webgo 13.5% (51091 vs 6881)
wicket 12.7% (66441 vs 8431)
wsgi 14.8% (21139 vs 3138)
I found it interesting that something like tapestry took a 20x slowdown when going from dedicated to ec2, while others only took ~5x slowdown.
Edit: To hopefully make it clearer what the percentages mean - if a framework is listed at 20%, this means that the framework served 1 request on ec2 for every 5 requests on dedicated hardware. 10% = 1 for every 10, and so on. So, higher percentage means a lower hit when going to ec2.
Disclosure: I am a colleague of the author of the article.
You're saying that running a query across the internet to ec2 is 5 times faster than running it on dedicated hardware in the lab? I find that hard to believe.
Sorry, maybe my original post was not entirely clear. Let's take tapestry, for example. On dedicated hardware, the peak throughput in responses per second was 75,002. On ec2, it was 3,901 responses per second.
So, in responses per second, the throughput on ec2 was 5.2% that of dedicated hardware, or approximately 20 times less throughput. The use of the word slowdown was possibly a bad choice, as none of my response had to do with the actual latency or roundtrip time of any request.
cake 18.9% (312 vs 59)
compojure 12.1% (108588 vs 13135)
django 16.8% (6879 vs 1156)
express 16.9% (42867 vs 7258)
gemini 12.5% (202727 vs 25264)
go 13.3% (100948 vs 13472)
grails 7.1% (28995 vs 2045)
netty 18% (203970 vs 36717)
nodejs 15.6% (67491 vs 10541)
php 11.6% (43397 vs 5054)
play 20.6% (25164 vs 5181)
rack-jruby 15.6% (27874 vs 4336)
rack-ruby 22.7% (9513 vs 2164)
rails-jruby 22.7% (3841 vs 871)
rails-ruby 20.7% (3324 vs 687)
servlet 13.4% (213322 vs 28745)
sinatra-jruby 21.2% (3261 vs 692)
sinatra-ruby 22.2% (6619 vs 1469)
spring 7.1% (54679 vs 3874)
tapestry 5.2% (75002 vs 3901)
vertx 22.3% (125711 vs 28012)
webgo 13.5% (51091 vs 6881)
wicket 12.7% (66441 vs 8431)
wsgi 14.8% (21139 vs 3138)
I found it interesting that something like tapestry took a 20x slowdown when going from dedicated to ec2, while others only took ~5x slowdown.
Edit: To hopefully make it clearer what the percentages mean - if a framework is listed at 20%, this means that the framework served 1 request on ec2 for every 5 requests on dedicated hardware. 10% = 1 for every 10, and so on. So, higher percentage means a lower hit when going to ec2.
Disclosure: I am a colleague of the author of the article.