Hacker News Reader

Comment by tempestn | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com