There are some stress tests for mummy, see the readme: <https://github.com/guzba/mummy#benchmarks>
But I don't think synthetic stress tests are useful here, besides telling you it's good enough. They pretty much converge to the same value. If you just run the webserver that does practically nothing, the async stuff will be faster. But as I learned the hard way, a single blocking operation or cpu intensive operation can really lower the performance of your async server. Blocking or CPU intensive operation are really hard to find and get rid of. Any library, os and any API call can be that. Are you talking to a database (can randomly block)? Are you talking to an API (DNS resolution blocks)? Are you parsing json (can be CPU intensive for large amounts)? Are you reading a file (blocks)? This is where mummy wins, because now each request can go into a thread and can be on its own core. Unlike the old threaded server model, the I/O is done in dedicated reactor/async thread, it isolates your code reading/writing to socket using HTTP. Your code runs in a thread and can block and do CPU stuff, and with modern computers having so many cores its a good fit. And mummy can have 1000 threads... that's why it works.
