What webserver is best? More specifically for static content

nginx

apache is simpler but worse performing

haven't tried any of the newer ones like caddy, etc

nginx, for everything both static and dynamic with backends (php-fpm, node, whatever else u can think up)
nginx is so good, cloudflare base their entire god damned company on it, there is nothing better, nor simpler to use.

>>61632737
Not true. PHP is a bottleneck that makes apache and nginx performance the same.

>>61632401
darkhttpd, is only for static content, no compromise for anything more

>>61632868
but that's wrong, because fastcgi cache exists, apache doesn't have anything of the sort. google "nginx microcache", be amazed my small child.

File: 1500151383410.jpg (42KB, 600x740px) Image search: [Google]

42KB, 600x740px

>>61632955
Holy shit you may be on to something

>>61632401
nginx hands down. Used to run Apache, moved to nginx, it's so much better. Designed form the ground up to be multi-threaded, super-light, config is slightly different to apache but I think it's laid out better. Hell, if you bung up the config and tell it to restart it'll say "nah your config is fucked, fix it first, until then I'll keep running with the old config", which is great for lowering downtime.

>>61633057
yep, my only gripe with nginx is it's not always intuitive on how to do things, lots of back and forth with reading the wiki to make sure the rules will do what you envision

>>61633055
oh I know I'm right don't you worry, I maintain a few sites in the top5k of alexa that regularly get hammed and I've spent MANY hours fine-tuning performance. nothing comes close to nginx, it uses the least resources and nets you the best performance. anyone that tells you otherwise is trying to sell something to you.

the nginx community is great, and there are pre-defined rules for almost anything you could think of doing (including microcaching) and weird triple/quad IF statement rules if you the need arises. the syntax isn't too bad either, takes a little to get used to, but once you get a grip of the basics you're golden.

Now that Nginx works with .NET Core, Nginx.

>>61632401
I typically just use nginx. Dead simple to add new sites to my vps. I just copy paste the config for my main site, edit the directory it looks for the site, and edit the domain that it uses.
There might be some hipster software that is faster but nginx is very simple to get up and running

Apache has a nicer configuration language compared to nginx in my opinion, sometimes the .htaccess configuration mecanism is useful to quickly try something out, the reference documentation is always up to date and rather readable, though the more didactic resources tend to be outdated, the mod_<language> allow you to fuck around with programs without having to integrate your logic with a webserver upfront (unless you want to have full and finer-grained control on the http requests and responses). You can also switch the worker to an evented one if your application supports it, although it doesn't always help since most stuff apache does still uses threads, such as compression. You don't need performance under heavy concurrent load that often, so apache httpd is just fine for many workloads. Your application might do concurrency with threads anyway and be slower to respond to requests than any webserver you'll put in front of it; in those cases there's no point in ditching the large ecosystem, nicer syntax and better documentation of apache.

That said, on my computer I use nginx to serve files and proxy my homepage application as it starts faster than apache, and that matters more than anything else in that context because it directly translates to boot time. For the small websites I manage I prefer apache though.

>>61633091
u wat m*, nginx is a damn pleasure to use

>>61633983
Ok, where are the full specs of the configuration language? No, not the source code, something with words.

>>61632401
unironically you don't need anything except node.js and socket.io to make a better performing clone of every website on the planet.