[astrange]

> It did all that while still being a reasonably good workhorse for static file serving (when properly turned and using the right worker model, event rather than threaded or process).

event doesn't support HTTPS, or rather, it stops being event-based when you turn on HTTPS. So Apache can never be performant unless you have an SSL terminating proxy.

Its only advantage is that the config script is slightly easier to test, but it's still way too hard _and_ it's incredibly verbose compared to nginx config.

[xorcist]

> event doesn't support HTTPS, or rather, it stops being event-based when you turn on HTTPS

Have you got any reference to this? I think I should have noticed, having run Apache with fairly bursty traffic.

The only reference in the documentation was a four year old one, which said it was problematic six years prior to that...

I find the Event MPM to be very stable under pressure and unless you have some really specific need it's the only sane way to run Apache. It should have been the default ages ago (in the limited sense Apache even has defaults).

[astrange]

Hmm, it seems like it works now in 2.4. That's a reason to keep Apache but I still can't see a reason to run anything new on it.

[xorcist]

2.4 is only five years old. 2.2 is more likely, if it was fixed ten years ago. In the few cases I have built Apache I usually don't bother with DSOs, and I usually run only the Event MPM.

The basis you pick your web server on shouldn't be whether it's "new" or "old". It is what your software runs on, what support contracts you have, and what functionality you need. But don't use it if you can't configure it. Preferrably your organization should have knowledge about every piece of software in production.