Hacker News Reader

I started using Apache again in 2019. I wanted to set up WebDAV file sharing on my home network, and Apache's implementation of WebDAV was more compatible than nginx's. Even with https://github.com/arut/nginx-dav-ext-module, I had problems with Windows clients on nginx. Caddy 2, my go-to HTTP server, lacked a WebDAV plugin at the time. So I tried Apache, and WebDAV worked everywhere. (Since then https://github.com/mholt/caddy-webdav has come out for Caddy. I plan to test it for compatibility, but I am happy with Apache and don't see a need to migrate.)

While setting up Apache 2.4, I came to like certain things about it. For example, https://httpd.apache.org/docs/2.4/mod/mod_macro.html. Configuration seems less footgun-y than that of nginx (see https://news.ycombinator.com/item?id=30435282). I have also adopted https://tcl.apache.org/rivet/ and use it on the LAN server where someone else might reach for PHP. It is admittedly quite niche.

The only time in the last ten years that I've reached for Apache was when I needed to put an LDAP auth reverse proxy on something— it looked like it was possible to do it with nginx, but would require running a separate script or dealing with Lua or something. On Apache it was batteries-included and a few lines of pasted-in config file.

I'd love to be shown a better way on that, but Apache did rack up a W for that one use case.

Traefik, bruv

Caddy, hands down the most sane webserver config for a reverse proxy.

Thanks! That does look pretty reasonable: https://authp.github.io/docs/authenticate/ldap/ldap

I often find random parts of nginx hidden behind their paywall, and then I'll reach for Apache. Especially when creating load balancers

If you're on Linux, you could use haproxy

I made mistakes in the Caddy part of the parent comment. Let me correct them.

> Caddy 2, my go-to HTTP server, lacked a WebDAV plugin at the time. [...] Since then https://github.com/mholt/caddy-webdav has come out for Caddy.

1. I have discovered that Matt Holt published the WebDAV plugin shortly before the launch of Caddy 2. So there was never a time when Caddy 2 was officially out and without a WebDAV plugin. I found out about the plugin later.

2. Caddy 2 actually launched in 2020, and I set up my server in 2019, when I only used Caddy 1. Caddy 1 did have an unofficial WebDAV plugin, https://github.com/hacdias/caddy-v1-webdav. I remember finding some compatibility issue with it, too.

> awful Apache prefork engine

Eh, the prefork engine isn't awful. It's not without limitations, but it's an excellent fit for some loads and a bad/terrible fit for others.

The main limitations are:

The child ramping behavior: you should set MinChildren = MaxChildren = StartChildren. Ramping children on demand sounds nice, but it's easy to run out of memory when all the children start or spend too much time on childinit instead of serving requests.

Anytime the child spends connected to a client socket but not actively working. Some of this can be mitigated. Turning off http keepalive (or handling it elsewhere) and setting large socket buffers allows the server to generate a response, give it to the kernel, and move on to the next client. If you're often waiting significantly for disk i/o, Apache pre-fork isn't a good fit.

Http keep-alive is a big deal for some uses, Yahoo had a nice hack for that, which I don't think made it out: have sockets wait for complete requests in another process, and send those sockets to apache over a unix socket; after apache is done with it, send it back to the 'cheapalive' daemon. That adds a bit of complexity, and I don't know of a public implementation, so not super useful to people, but it's possible to build.

I personally think prefork apache + mod_php is simpler than some other daemon + fastcgi php. But that's debatable.

Edit: oh and one more... .htaccess is clearly a performance suck. Perhaps a useful one depending on your application, but there's good reasons nobody else does it.

The April 2023 Netcraft survey: https://news.netcraft.com/archives/category/web-server-surve...

nginx is at: 26% Apache is at 20%

It doesn't sound like nginx is even close to having this wrapped up; which is a really good thing because I've tried nginx and the config and design sucks. Apache does so many things well.

That's most likely all cpanel php WordPress stuff that relies on .htaccess files

That chart counts nginx and openresty as separate categories. If you combine them (which I think makes more sense, since a lot of openresty's adoption must come from ingress-nginx), nginx/openresty would be at 34%.

Either way I'm happy with a wide variety of products doing the job, it avoids lock-in.

Personally I use apache as I have very few users (internal facing stuff), it has a nice simple mod_auth_openidc config which remains the same from one year to the next

I do have to recompile ws_tunnel though as I proxy a broken product I proxy which doesn't accept the correct standard for camel-capped "WebSocket" -- my "fix" script runs

sed -i 's/WebSocket/websocket/g' ./modules/proxy/mod_proxy_wstunnel.c

and recompiles

> As of June 2022 W3Tech's web server count of all web sites ranked Nginx first with 33.6%. Apache was second at 31.4% and Cloudflare Server third at 21.6%.

From the wiki.

It's interesting, it sounds like Apache is closer than I thought. I posted Netcraft's link since I've followed them for years, I'm not as familiar with W3Tech. I can't speak to which has more reliable data but W3Tech's numbers doesn't surprise me.

Is nginx still considerably more performant than Apache when both are configured well? (IE. Using mpm_event, not needlessly recycling processes, using mostly threads for concurrency, etc.?)

I'm one of those who always just stuck with Apache because 1) I'm used to it, and 2) it's never been close to a bottleneck in our stack. Especially now that the vast majority of static content requests don't even hit the servers at all. Buy I am curious! I haven't looked at comparisons in years, but last I did, everyone liked to compare nginx to prefork Apache, which is pointless.

HAProxy is faster than both of them for load balancing. Apache is slightly faster for static content. Nginx has more responsiveness under high load than Apache for dynamic content (Hence Tomcat workers for example)

Is that true even if you configure Apache to use a static number of processes? IE set startservers equal to serverlimit and maxsparethreads equal to maxrequestworkers? IME that allows Apache to respond to load spikes more quickly. But is the issue with high load and dynamic content specifically related more to connecting to the process manager for the scripting language? (I take the same approach there, using a static pool of processes. Haven't had any issues, but have no way of knowing if nginx might be even faster!)

Nginx uses an event driven model where a single thread might perform work for multiple requests. Often the batching and caching of these requests can boost performance. Apache however assigns each inbound connection its own dedicated thread which makes it slightly more responsive on average. At the end of the day it's going to come down to the priority of scheduling for the threads of the program whether it be one process with 65,535 threads or 65,535 single threaded processes

That description is not correct for any of them. Apache can use either an event queue or a thread pool, and nginx is also multithreaded and not forking. So there isn't any difference, except that Apache has a bit more knobs to tweak.

NGINX is multiprocess Single Threaded Apache is one thread per connection

Its like having the same waiter vs a pool of waiters

Sources: https://serverguy.com/wp-content/uploads/2020/10/Apache-Vs-N...

https://www.google.com/search?rlz=1C1CHBF_enUS874US874&sxsrf...

That is just a png of some text. The text is either wrong or outdated by a decade or more.

People sometimes like to have opinions about stuff. But there's no reason to google for secondary sources when the documentation is good.

Read the manual instead. The documentation for both projects is correct, short and to the point. They are both multi threaded, multi process, with an event loop. The documentation describes how to set those parameters. Look at the thread_pool directive for nginx and AsyncRequestWorkerFactor for Apache for example.

You could of course configure one thread per connection, but that only makes sense under specific circumstances.

Does Apache can do zero-copy for static content? nginx could on properly configured system.

TLS kills this, alas, and, I think, with TLS OpenSSL will be bottleneck for static content, not server.

I think it has more to do with the event driven nature of nginx vs the thread per connection nature of Apache.

If you're looking for this, you want kTLS, plus or minus nic accelerated kTLS. Read the Netflix CDN presentiatons for the state of the art, and see what you can make work with your system, etc.

I know abut Netflix work, and even some of this work trickled down to base FreeBSD (and opensource), but is still very fragile, not completely open-sourced and require very special hardware (1 or 2 models of specific NICs with specific versions of firmware) to work.

"EnableSendfile On" will enable that on Apache, and has been around since Apache 2.0.44. It's not enabled by default though, and as you say, TLS breaks it.

For 99% of use cases webserver speed is rarely an issue.

> For 99% of use cases webserver speed is rarely an issue.

OK. But you might as well use a fast setup if there's no cost in complexity to do so.

Rule 1: there is always a complexity cost

We switched from Apache to lighttpd back in the day specifically for performance issues; the other option would have been to add a new server. This wasn't "Facebook scale": just a small company with 2 devs running a few sites with quite a lot of pageviews.

Since then computers (and presumably also Apache) have become faster and I don't really know how it compares today, but at least in the past it really did make a significant enough performance difference to care about.

Were you using mpm_prefork on apache, or one of the threaded process managers?

This was over 10 years ago... We tried a few things; I don't recall the details. I assume we tried this.

Getting Apache from distro repos is like using MS Word and Nginx like Notepad. Rarely you use all the features available on Apache but, mostly at the beginning, compiling Nginx to get features was the daily routine.

I still use Apache Httpd quite a bit, actually. Alongside haproxy, that is. The thing I appreciate about Apache is its modular layout. With Nginx I often run into a use case where I need to recompile stuff, something that never happened to me with Apache Httpd.

> often run into a use case where I need to recompile

Which use case is that?

for example geoip2 support

Debian have it pre-packaged as nginx module.

Note, just in case, that nginx already has support for dynamic modules, and you don't have to rebuild it to add functionality.

Unless you're from Canada, Alaska or Norway this saying will make absolute no sense to anyone:

> like fresh snow under foehn

Works for Germany too, since a Föhn is either a kind of warm wind, or a hair dryer.

The hairdryer is the Fön without h.

Since the spelling reform of 1996 both are spelled Föhn

Same in Switzerland, even in the French speaking part

Same for Dutch. It's the common name for a hair dryer.

You get it also under the Alps

"Fohn" is an English word directly derived from "foehn".

I am from none of those places, speak no relevant languages other than English, and I had no trouble with the phrase in question.

I appreciate your effort in trying to stick up for me, though (: Perhaps if you want to be more helpful for those people who do conform to your assumptions, you could share a definition, in addition to your criticism.

"Fohn, an Englosh derivate of 'foehn', means 'a warm, dry wind', and is known for being particularly effective at melting snow."

I am from a native English speaking country and I had never heard the word foehn or fohn in my life, so assumed it was a typo of foot.

Which coincidentally happens to have a similar contention as standing on fresh snow compacts it, but only from the comments did I guess it was supposed to be a melting analogy.

In German its Föhn which can be written as Foehn

I am from Canada and I have no idea what this means

"Chinook" is the term I've heard used for this.

https://en.wikipedia.org/wiki/Chinook_wind

In southern California they call them Santa Ana winds.

I had to look it up. I like the word.

Norway here, but I didn’t get it. First guess was that foehn meant foot/feet, but I was way off according to the other comments

We only use it for badly designed software that uses mod_rewrite rules as integral part of the application and not just "set those 3 rules to direct it to the entry point".

some peoples badly designed software is other peoples micro services

The problem with mod_rewrite rules is that:

* applications are built to change them dynamically, making them part of application code, instead of you know... just having proper request router in app

* It is not "enter URL in, get rewritten URL out". You can do conditionals based on existence of files and a bunch of other stuff which means it can't be isolated from the app overusing it easily

Rewriting on loadbalancer to mangle some paths is to be avoided but overall not too bad to manage but what can happen in mod_rewrite by badly designed apps make app basically glued in into apache.

Before nginx there was lighttpd that was pretty much what Nginx would be later on.

I still use Lighttpd. My weird idea why Lighty lost the war is that it had somewhat unorthodox rewrite rules, namely this one line in mod_rewrite.c:

if (st && S_ISREG(st->st_mode)) return HANDLER_GO_ON;

Change it to if (st) without a regular file check, and it works as expected (great) with frameworks like Joomla etc (/administrator URLs, for example)

I used lighttpd for my previous job because the boss liked. The config language was definitely weird. I had to do a lot of fixups when someone made a well meaning change that didn't work properly because of how conditionals work. Usually informed by experience from when the someone was me.

I personally ditched lighttpd on my own website (PHP, large traffic, but only a single server) because it had some memory leak that would, over time, result in increasing memory usage and eventually cause the server to chug.

It had not seen any bugfix releases for quite a long time at that point, and nginx was available by then, so I made the swap. I continued to serve that website off of a single server for the rest of its lifetime.

Nope. lighttpd is simple and light.

nginx is very powerful and fast.

nginx could send static file with one syscall and zero-copy if OS supports it. It could exploit all system async mechanisms - POSIX AIO, kqueue, whatever you have. Linux was worst in this regards before io_uring, and FreeBSD or Solaris were much, much better platform for nginx.

For example, Igor Sysoev (mastermide behind nginx) pushed patches to FreeBSD kernel to shave off one syscall per file on this system.

Now, when everything is HTTPS, Linux have io_uring and Igor left nginx after F5 acquisition, it is not very useful - nginx is stagnating, support for KTLS is absent, support for io_uring on Linux is absent (though there are some forks and patches for this)...

But compare nginx and lighttpd is simply stupid, it is apples-to-oranges comparison.

Each one has its niche, of course.

lighttpd came out in the mid 2000's with a better polling model than Apache, that was my point. It was using epoll back then which Apache did not.

Even Youtube used Lighttpd at some point.

Both are http servers, and lighttpd came out before Nginx, they both tried to solve the c10k problem.