Setting aside, for the moment, brian d. foy's tongue-in-cheek demolition of benchmarking as a valid tool, what do we learn from these?
Actually, mostly, we learn that a single instance of almost any web app written in just about any language on semi-decent hardware, pounded on by JMeter, ab or whatever will cough up well over 100 hits/second without actually breaking into much of a sweat.
Let's stop right there for our first remedial maths class, OK?
That's 6,000 hits a minute. 360,000 hits an hour.
Eight point six million hits a day. And change.
And that's page views - c'mon, you don't serve your static images out of of your webapp framework. That's a dickens of a lot of traffic. To give you an idea, CricInfo.com's record month while I was there was a quarter of a billion page views... that's about 8.3 million a day on the biggest single-sport website on the net.
You're expecting that amount of traffic? Man, do you have delusions of grandeur! Paying for the bandwidth is going to be a much bigger worry than whether your web app framework can cope.
Stick an ad on every page, from Y!, Google, whoever. A week's traffic, tops, and you can afford another server. Hell, you can afford two and a load-balancer. And quite frankly, your rate-determining step is almost certainly NOT how fast your underlying development framework can generate the pages, but how well-written your code and your DB are, how cacheable the pages are, how big they are, and how laggy your average client is. One missing database index can turn a 0.02s query into a 3s query.
Get over it, folks.
[composed and posted with ecto]