[pekk]

and I just got finished rewriting all my large webapps in some obscure Java framework for performance, because of some benchmarks I saw on HN. Guess now I have to rewrite it all in assembly, because more performance is always better right?

[yeukhon]

Well, the JVM might be doing something smarter than your assembler-from-scratch code.

[anonymouscowar1]

This is not a very fast webserver. Anything using sendfile() and threads/processes will beat it handily.

[kragen]

I haven't measured, but I'm pretty sure you're right.

[anonymouscowar1]

Me too. You could probably find a single-threaded, small file benchmark where they compare similarly (or this even compares better — it does almost nothing). But this is not most benchmarks. Large files or multiple clients will bench this server poorly compared to MT + sendfile(2).

This server is single threaded and artificially serializes requests, at a minimum. The copy through userspace is going to hurt compared to sendfile for larger files.

[kragen]

I made it fork. Now, on my netbook, it's able to handle in the neighborhood of a thousand requests per second and 20 megabytes per second, with up to 2048 concurrent connections. Not, I think, spectacular performance, but acceptable for many purposes. You can still DoS it by opening 2048 concurrent connections to it; as long as they are open, it will open no new connections, and it has no timeout.

This has bloated the executable up to 2088 bytes.