5 ms·

What's the pro / con of using Apache vs Nginx these days?

davidgerard 9y ago
Neutral: * You are probably not Google and the http/https server is almost certainly not a performance problem worth worrying about. Pro-Apache: * Swiss army knife. At my day job we use a pile of Apache modules; if we went nginx we'd have to replace these with a kitchen drawer full of standalone gadgets. * You know Apache well. * Lots of LAMP apps pretty much presume Apache (WordPress plugins in particular) and nginx support is a me-too. Pro-nginx: * Smaller and cleaner config. * You know nginx well. * nginx support is getting better, if you like nginx it's worth checking your prospective application. Honestly, for almost all use cases it probably doesn't matter which. Pick whatever makes you most effective.
- cookiecaper 9y ago
  One point against nginx: it's an "open core" product. The free/OSS version lacks features so that Nginx Inc. can sell them to companies.
  - Twirrim 9y ago
    Which includes super fun stuff like if you're proxying to a back end by name it only resolves the IP on either start-up or first connection (not sure which), unless you specifically add a static DNS resolver IP address and do some variable stuff. When your upstream DNS resolver stuff could change, that tends to mean you need to install DNSMasq and similar locally and point your nginx to it. Fixed in Plus, not in the open source product.
    - davidgerard 9y ago
      So nobody's fixed this in a fork?
      - nine_k 9y ago
        Supporting a fork, or even a patch set, is a lot of work. Especially if you know full well that it's never going to be accepted upstream. And unless you support it solidly and long-term, nobody would really use it: paid support from Ngnix is much less risk.
      - ptman 9y ago
        There's the tengine fork: http://tengine.taobao.org/ http://tengine.taobao.org/ https://github.com/alibaba/tengine https://github.com/alibaba/tengine
tbrock 9y ago
Well, the best pitch I've heard for nginx is: "Come for the performance, stay for the configuration".
- astrodust 9y ago
  The Nginx configuration format is a lot more coherent than the Apache httpd equivalent.
user5994461 9y ago
It's 99% of the same. Green apple and red apple. If you have an existing configuration written in any, it invariably ended up as a pile of hacks, domains and misredirections that is a pain to rewrite for the other. That makes it hard to change. Apache has support for some modules, mostly for authentication, that nginx doesn't have. Old applications, like wordpress, are only supported and documented on Apache.
- dullgiulio 9y ago
  > Old applications, like wordpress, are only supported and documented on Apache. Wordpress is not old, it is just very badly written.
- aduth 9y ago
  >Old applications, like wordpress, are only supported and documented on Apache. Not true: https://codex.wordpress.org/Nginx https://codex.wordpress.org/Nginx
  - RKearney 9y ago
    > This page is marked as incomplete. You can help Codex by expanding it. I've been using WordPress on Nginx for almost a decade now, I just found that bit funny given the context.
- davidgerard 9y ago
  > Old applications, like wordpress, are only supported and documented on Apache. WordPress itself is fine. Many plugins, however, assume Apache (and MySQL).
jeltz 9y ago
I find nginx easier to use and their documentation better. On the other hand Apache has some features which are missing from nginx like supporting client certificate authentication only on a specific path. Either will probably solve your use case just fine.
combatentropy 9y ago
One of my favorite features of Apache is MultiViews. It lets me make a file like this: www.example.com/widgets.html and this address without the file extension will work: www.example.com/widgets If the file is widgets.php or some other language that Apache considers a script, then even this will work: www.example.com/widgets/1234 and $_SERVER['PATH_INFO'] will be set to /1234. This is all turned on with one line in a configuration file: Options +MultiViews instead of having to turn on mod_rewrite, with its complexity.
berns 9y ago
One difference that I think is important: no .htaccess in nginx. So the only way to change any configuration in nginx is in the configuration files and a server restart is necessary.
- ag_47 9y ago
  Note that this is intended and desirable for any server with moderate to high loads. Plus, Nginx can reload its configuration gracefully without dropping connections.
  - tqkxzugoaupvwqr 9y ago
    For the uninformed: The reason .htaccess is not desirable is that the server has to check each directory in the request path for an .htaccess file and read its content.
    - geofft 9y ago
      What's the actual effect of this? Negative filesystem lookups are cached, and I believe they're cached forever on local filesystems (since you know if anyone's writing to the local filesystem), so the overhead is just that of a couple of syscalls. That feels like it's small enough that you really want to benchmark to see if it matters for you.
      - combatentropy 9y ago
        No effect, on my server, a $5-per-month Digital Ocean droplet. Using the program called Apache Bench (ab) to retrieve a file four directories deep: /a/b/c/d/e.html With .htaccess files turned off (AllowOverride None), I got 282 requests per second. With .htacess files on (AllowOverride All) I got 286 requests per second (Yes, actually a few more hits per second with .htaccess turned on, but the results swing from test to test by a few percent anyway).
LinuxBender 9y ago
Apache is stable, rarely any security related issues; and even then, it's usually a module not installed/enabled by default. Nginx and Apache are about the same performance, assuming you are on 2.4.x and using the latest apr/apr-util/apr-iconv. The memory footprint is about the same and benchmarks are about the same. Nginx still hard codes libc options that I have to undo in the Makefile each time to get the glibc hardening options enabled. (PIE, Full RELRO, stack protector and so on) I have not tested the last 3 or so releases, so maybe Maxim has resolved this? I prefer Apache for anything CGI related, as the security is more tightly coupled to the webserver. With NGINX, I have to use another daemon that has it's own security settings, environment, etc.

Neutral: * You are probably not Google and the http/https server is almost certainly not a performance problem worth worrying about. Pro-Apache: * Swiss army knife. At my day job we use a pile of Apache modules; if we went nginx we'd have to replace these with a kitchen drawer full of standalone gadgets. * You know Apache well. * Lots of LAMP apps pretty much presume Apache (WordPress plugins in particular) and nginx support is a me-too. Pro-nginx: * Smaller and cleaner config. * You know nginx well. * nginx support is getting better, if you like nginx it's worth checking your prospective application. Honestly, for almost all use cases it probably doesn't matter which. Pick whatever makes you most effective.

cookiecaper 9y ago
One point against nginx: it's an "open core" product. The free/OSS version lacks features so that Nginx Inc. can sell them to companies.
- Twirrim 9y ago
  Which includes super fun stuff like if you're proxying to a back end by name it only resolves the IP on either start-up or first connection (not sure which), unless you specifically add a static DNS resolver IP address and do some variable stuff. When your upstream DNS resolver stuff could change, that tends to mean you need to install DNSMasq and similar locally and point your nginx to it. Fixed in Plus, not in the open source product.
  - davidgerard 9y ago
    So nobody's fixed this in a fork?
    - nine_k 9y ago
      Supporting a fork, or even a patch set, is a lot of work. Especially if you know full well that it's never going to be accepted upstream. And unless you support it solidly and long-term, nobody would really use it: paid support from Ngnix is much less risk.
    - ptman 9y ago
      There's the tengine fork: http://tengine.taobao.org/ http://tengine.taobao.org/ https://github.com/alibaba/tengine https://github.com/alibaba/tengine

tbrock 9y ago

Well, the best pitch I've heard for nginx is: "Come for the performance, stay for the configuration".

astrodust 9y ago
The Nginx configuration format is a lot more coherent than the Apache httpd equivalent.

user5994461 9y ago

It's 99% of the same. Green apple and red apple. If you have an existing configuration written in any, it invariably ended up as a pile of hacks, domains and misredirections that is a pain to rewrite for the other. That makes it hard to change. Apache has support for some modules, mostly for authentication, that nginx doesn't have. Old applications, like wordpress, are only supported and documented on Apache.

dullgiulio 9y ago
> Old applications, like wordpress, are only supported and documented on Apache. Wordpress is not old, it is just very badly written.
aduth 9y ago
>Old applications, like wordpress, are only supported and documented on Apache. Not true: https://codex.wordpress.org/Nginx https://codex.wordpress.org/Nginx
- RKearney 9y ago
  > This page is marked as incomplete. You can help Codex by expanding it. I've been using WordPress on Nginx for almost a decade now, I just found that bit funny given the context.
davidgerard 9y ago
> Old applications, like wordpress, are only supported and documented on Apache. WordPress itself is fine. Many plugins, however, assume Apache (and MySQL).

jeltz 9y ago

I find nginx easier to use and their documentation better. On the other hand Apache has some features which are missing from nginx like supporting client certificate authentication only on a specific path. Either will probably solve your use case just fine.

combatentropy 9y ago

One of my favorite features of Apache is MultiViews. It lets me make a file like this: www.example.com/widgets.html and this address without the file extension will work: www.example.com/widgets If the file is widgets.php or some other language that Apache considers a script, then even this will work: www.example.com/widgets/1234 and $_SERVER['PATH_INFO'] will be set to /1234. This is all turned on with one line in a configuration file: Options +MultiViews instead of having to turn on mod_rewrite, with its complexity.

berns 9y ago

One difference that I think is important: no .htaccess in nginx. So the only way to change any configuration in nginx is in the configuration files and a server restart is necessary.

ag_47 9y ago
Note that this is intended and desirable for any server with moderate to high loads. Plus, Nginx can reload its configuration gracefully without dropping connections.
- tqkxzugoaupvwqr 9y ago
  For the uninformed: The reason .htaccess is not desirable is that the server has to check each directory in the request path for an .htaccess file and read its content.
  - geofft 9y ago
    What's the actual effect of this? Negative filesystem lookups are cached, and I believe they're cached forever on local filesystems (since you know if anyone's writing to the local filesystem), so the overhead is just that of a couple of syscalls. That feels like it's small enough that you really want to benchmark to see if it matters for you.
    - combatentropy 9y ago
      No effect, on my server, a $5-per-month Digital Ocean droplet. Using the program called Apache Bench (ab) to retrieve a file four directories deep: /a/b/c/d/e.html With .htaccess files turned off (AllowOverride None), I got 282 requests per second. With .htacess files on (AllowOverride All) I got 286 requests per second (Yes, actually a few more hits per second with .htaccess turned on, but the results swing from test to test by a few percent anyway).

LinuxBender 9y ago

Apache is stable, rarely any security related issues; and even then, it's usually a module not installed/enabled by default. Nginx and Apache are about the same performance, assuming you are on 2.4.x and using the latest apr/apr-util/apr-iconv. The memory footprint is about the same and benchmarks are about the same. Nginx still hard codes libc options that I have to undo in the Makefile each time to get the glibc hardening options enabled. (PIE, Full RELRO, stack protector and so on) I have not tested the last 3 or so releases, so maybe Maxim has resolved this? I prefer Apache for anything CGI related, as the security is more tightly coupled to the webserver. With NGINX, I have to use another daemon that has it's own security settings, environment, etc.