Right, but that's also why defaulting to the core count seems like a good idea because any CPU-bound workloads (which includes a lot of benchmarks, like this one in question) will basically perform optimally. Accepting more than the CPU core count will just add overhead through contention.
I'm curious why NIO / Vapor use this architecture, as opposed to an idle-acceptor? (dunno if that's the canonical term, but in short: run one thread per core and whenever that thread idles, accept another connection) I realise that's not easy to actually implement (for non-trivial handlers, i.e. anything which blocks or yields), but it's what I've seen work well in production.
Does Vapor support deadlines, to any degree? e.g. immediately terminate requests which are unlikely to succeed in time anyway, and/or cancel requests in flight if they exceed a deadline? I haven't explored it first-hand, but I've heard that this can be a substantial boon for overall success rates in overload situations.
(or, the simpler approximation via LIFO request handling?)