1000req/s is good, though what's the backend doing then? Also, what kind of concurrency have you got going with that benchmark? I've developed a few proprietary high-availability/high-throughput web servers, and you learn very quickly that what you thought was great performance can fall down around you when you start passing -c to ab.

Testing one such thing I wrote now; it's used in production with months of uptime (i.e. it's very stable and feature-complete), and hooks into a variety of networks and network types.

At 1000 concurrent requests, it's serving about 18,000req/s on my not-too-impressive Core i5-450M (notebook) -- and that's because it's doing nothing but serving a very simple static page (and because it's written in C). The most complicated thing it's doing is reading the request, dispatching it to the correct endpoint, and writing the response into a buffer to be shunted onto the network.

My point (other than comparing apples and oranges) is that, being the underlying framework, you can never be too fast, as you don't know what someone's going to put on top of it. Serving tens of thousands of requests per second is a nice baseline. Frankly, so is serving nearly a thousand, but just a reminder not to settle for "good enough".

Anne