I see several posts discussing under which circumstances or use cases one might outperform the other but they never seem to care about having decent metrics.
I might overrate the importance of this, who knows...
The last frontier for these types of comparisons is unusual circumstances like embedded platforms with limited resources.
I'd say that it's possible, just not always easy, due to how many different configurations there can be for any given workload - the same servers might be used to achieve the approximately same configuration in different ways.
However, if you took a common enough use case or workload, such as reverse proxy with SSL and gzip compression for $FOO resource types, serving files for $BAR application and proxying $BAZ API, then it should definitely be possible. You would just need some meaningful real-world test instead of a purely synthetic benchmark, otherwise you'll probably test something slightly different than what your server will be doing in practice.
The other option is just to settle on some bit of common enough functionality and try to increase your sample size as much as possible.
For example, some attempts have been made by OpenBenchmarking and at least give a vague idea of the performance of some servers:
Nginx: https://openbenchmarking.org/test/pts/nginx
Apache:https://openbenchmarking.org/test/pts/apache
I'm mentioning this because while not everybody has the time to reproduce a given setup in any number of technologies, even similar enough tests in a controlled environment can produce meaningful information, at least to let you infer what orders of magnitude you're working with. For something concerning programming languages themselves and their frameworks, one just needs to look at what TechEmpower is trying to do: https://www.techempower.com/benchmarks/#section=data-r21
> Really, you need to do your own benchmarking to determine which solution is best for you. But keep in mind that the web server is rarely the bottleneck, usually your app and database IO are where it takes the most time.
This is well said, though.
In general, I'm inclined to agree: most of the time, the performance of most web servers can be described as "good enough".
The exception to this might be using your application servers (e.g. Tomcat) as a web server and running into situations where serving static assets (that might be baked into your application) would slow down because of API calls being slower and processing them digging into comparatively more conservative HTTP thread limits for the whole thing. Then again, personally I'd argue that you should have one of the popular web servers in front of your applications (and typically serving static assets) to act as an ingress in most cases, but I've seen some interesting things over the years.
That's a perfectly valid use case!
Packaging a front end application (e.g. React/Angular/Vue) inside of a .jar file and making Tomcat or something else serve it, as a part of a larger Java application, though? Perhaps less of an optimal solution than just using Apache/Nginx/Caddy for it, outside of really wanting to be able to deploy everything as a single package.