4 ms·

This is a good thing. Apache is a swiss-army chainsaw of last-resort, not a minimal webserver.

muppetman 13y ago
Apache is very modular. You enable what you need. Apache's biggest problem is that it isn't cool and hip anymore. It's config file is too easy to understand. Good { thing we = have; nginx; } Phew!
- tiquorsj 13y ago
  It does have too easy of a config file. Who needs per directory config anyway? Or the ability to create redirects without a restart? I love nginx, but it has some flaws. The reality is it just has different flaws and strengths than Apache.
  - bluefinity 13y ago
    You can do per-directory config in nginx with the location block, it's just that you just can't put the config inside the directory itself and have nginx automatically load it. You can tell nginx to reload its configuration without restarting the entire server process by running "sudo /etc/init.d/nginx reload", or on ubuntu "sudo service nginx reload".
    - twic 13y ago
      'service' is not just on Ubuntu - i believe it started life on Red Hat, and has now spread everywhere. Including FreeBSD: http://www.freebsd.org/cgi/man.cgi?query=service&sektion=8 http://www.freebsd.org/cgi/man.cgi?query=service&sektion=8
      - bluefinity 13y ago
        Oh, I thought it was part of upstart for some reason. Thanks for the the clarification.
  - mercurial 13y ago
    I find the lack of dynamically loaded modules more aggravating, personally. Having to recompile and optionally repackage the damn thing because you need a module not included in the base nginx is a pain.
  - midas007 13y ago
    I <3 nginx and apache. Tech is a toolbox. Pick the closest tool for the job. Per directory config is extremely beneficial for static hosting / VPS, but sketchy to get the security of values just right.
- _ak 13y ago
  No, Apache's biggest problem is its architecture that limits quite a few things you can do. Case in point: the farce around mpm_event. It took ages to implement it to solve a central issue Apache always had (i.e. that it could be DoS'd by slow but long-living connections), and even now, it's not exactly in a great state, compared to nginx's async I/O internals.
  - liveoneggs 13y ago
    mpm_event in 2.4 is quite fast and let's you keep all of your terrible mod_rewrite hacks in place. :)
- reitzensteinm 13y ago
  Sounds like it's time for an anecdote! In 2008, my web site saw some decent traffic, and I was stuck in a spiral of buying more and more expensive servers to keep up with the demand. Some of the media files were large, and slow downloads would tie up a thread, and corresponding chunk of memory. I spent a long time working through the documentation that was available at the time, and I couldn't get anything to work stably with Django. Then I found a guide for lighttpd, and was floored when the resources used by my web server dropped to single digits. Much later, I'd learn that even saturating a gigabit pipe with just html/css/image traffic ran fine. Nginx has since replaced lighttpd, since the latter doesn't seem to be well maintained these days. As I understand it, Apache now is capable of high performance, but once bitten twice shy. The whole thing just seemed to be a big, bloated mess to me. Like you can do everything imaginable, except what you actually want to do. I couldn't imagine a feature that would exist to convince me to move back. I expect quite a few web developers are in the same boat. Your criticism of the config file is nonsensical. I'd use nginx with Apache style configuration over the inverse in a heart beat - though I disagree it would be an improvement.
  - midas007 13y ago
    I like servers that work reliably so the "pager" doesn't go off in the middle of the night nor get calls as to why our service is down.
- __david__ 13y ago
  > Apache's biggest problem is that it isn't cool and hip anymore. It's config file is too easy to understand. Yeah, mod_rewrite sure is the epitome of a readable config file syntax. Why have one or two simple to understand "if" statements when you could have a pile of incomprehensible regexps with random one letter control flow flags? Simple. Ha.
- midas007 13y ago
  Bikeshedding on config syntax isn't a valid critique. Apache uses tons of memory regardless of which worker model is used. Nginx is reliable and stable, we've never had memory leaks or weird shit happen. This is why it's often uses as a front-end reverse proxy. More often, nginx is put out in front of apache where other dependencies require it (dav svn).
clarry 13y ago
The fork of Apache 1.3 that OpenBSD had wasn't really that big. EDIT: The C source files and headers under src/usr.sbin/httpd are about 100k lines. Under src/usr.sbin/nginx you have closer to 170k lines. Of course this isn't exactly apples to apples comparison as both have optional modules and at least nginx has some OS-specific code. In any case though, it is really hard to argue that nginx is "light, small, and fast" while httpd is a bloated swiss army chainsaw with a kitten sink...
- dtech 13y ago
  Code size is in almost no way an indicator of performance or bloat. Ik can write a program that will use 100% CPU in about 10 LOC, while there can be very well-optimized pieces of software can be thousands to millions LOC. e.g. the Quake 3 engine is probably as well optimized as you can make it and is about 300K LOC: https://github.com/id-Software/Quake-III-Arena https://github.com/id-Software/Quake-III-Arena
  - clarry 13y ago
    In my book bloat and performance are two entirely different things, and I think there is a strong correlation between code size and bloat. I agree about highly optimized code being typically larger than the simpler alternative. Now nginx has interesting optimizations in some places (e.g. the http parser), but if you read the code, it's not like 90% of the code in nginx is there due to optimization. I'd like to add that from an OpenBSD perspective, excess optimizations would no doubt be considered bloat as well. One of the goals is that the code is clean, correct, and secure. I know for a fact that the developers are not going to carefully audit and maintain millions of lines of micro-optimizations. What these might get you is a tick in a hypothetical feature checklist ("performance"). But if another daemon does the job and performs well enough, then that feature is unneeded complexity, hence bloat. Not something you want to include in what aims to be the world's most secure general purpose operating system.

Apache is very modular. You enable what you need. Apache's biggest problem is that it isn't cool and hip anymore. It's config file is too easy to understand. Good { thing we = have; nginx; } Phew!

tiquorsj 13y ago
It does have too easy of a config file. Who needs per directory config anyway? Or the ability to create redirects without a restart? I love nginx, but it has some flaws. The reality is it just has different flaws and strengths than Apache.
- bluefinity 13y ago
  You can do per-directory config in nginx with the location block, it's just that you just can't put the config inside the directory itself and have nginx automatically load it. You can tell nginx to reload its configuration without restarting the entire server process by running "sudo /etc/init.d/nginx reload", or on ubuntu "sudo service nginx reload".
  - twic 13y ago
    'service' is not just on Ubuntu - i believe it started life on Red Hat, and has now spread everywhere. Including FreeBSD: http://www.freebsd.org/cgi/man.cgi?query=service&sektion=8 http://www.freebsd.org/cgi/man.cgi?query=service&sektion=8
    - bluefinity 13y ago
      Oh, I thought it was part of upstart for some reason. Thanks for the the clarification.
- mercurial 13y ago
  I find the lack of dynamically loaded modules more aggravating, personally. Having to recompile and optionally repackage the damn thing because you need a module not included in the base nginx is a pain.
- midas007 13y ago
  I <3 nginx and apache. Tech is a toolbox. Pick the closest tool for the job. Per directory config is extremely beneficial for static hosting / VPS, but sketchy to get the security of values just right.
_ak 13y ago
No, Apache's biggest problem is its architecture that limits quite a few things you can do. Case in point: the farce around mpm_event. It took ages to implement it to solve a central issue Apache always had (i.e. that it could be DoS'd by slow but long-living connections), and even now, it's not exactly in a great state, compared to nginx's async I/O internals.
- liveoneggs 13y ago
  mpm_event in 2.4 is quite fast and let's you keep all of your terrible mod_rewrite hacks in place. :)
reitzensteinm 13y ago
Sounds like it's time for an anecdote! In 2008, my web site saw some decent traffic, and I was stuck in a spiral of buying more and more expensive servers to keep up with the demand. Some of the media files were large, and slow downloads would tie up a thread, and corresponding chunk of memory. I spent a long time working through the documentation that was available at the time, and I couldn't get anything to work stably with Django. Then I found a guide for lighttpd, and was floored when the resources used by my web server dropped to single digits. Much later, I'd learn that even saturating a gigabit pipe with just html/css/image traffic ran fine. Nginx has since replaced lighttpd, since the latter doesn't seem to be well maintained these days. As I understand it, Apache now is capable of high performance, but once bitten twice shy. The whole thing just seemed to be a big, bloated mess to me. Like you can do everything imaginable, except what you actually want to do. I couldn't imagine a feature that would exist to convince me to move back. I expect quite a few web developers are in the same boat. Your criticism of the config file is nonsensical. I'd use nginx with Apache style configuration over the inverse in a heart beat - though I disagree it would be an improvement.
- midas007 13y ago
  I like servers that work reliably so the "pager" doesn't go off in the middle of the night nor get calls as to why our service is down.
__david__ 13y ago
> Apache's biggest problem is that it isn't cool and hip anymore. It's config file is too easy to understand. Yeah, mod_rewrite sure is the epitome of a readable config file syntax. Why have one or two simple to understand "if" statements when you could have a pile of incomprehensible regexps with random one letter control flow flags? Simple. Ha.
midas007 13y ago
Bikeshedding on config syntax isn't a valid critique. Apache uses tons of memory regardless of which worker model is used. Nginx is reliable and stable, we've never had memory leaks or weird shit happen. This is why it's often uses as a front-end reverse proxy. More often, nginx is put out in front of apache where other dependencies require it (dav svn).

clarry 13y ago

The fork of Apache 1.3 that OpenBSD had wasn't really that big. EDIT: The C source files and headers under src/usr.sbin/httpd are about 100k lines. Under src/usr.sbin/nginx you have closer to 170k lines. Of course this isn't exactly apples to apples comparison as both have optional modules and at least nginx has some OS-specific code. In any case though, it is really hard to argue that nginx is "light, small, and fast" while httpd is a bloated swiss army chainsaw with a kitten sink...

dtech 13y ago
Code size is in almost no way an indicator of performance or bloat. Ik can write a program that will use 100% CPU in about 10 LOC, while there can be very well-optimized pieces of software can be thousands to millions LOC. e.g. the Quake 3 engine is probably as well optimized as you can make it and is about 300K LOC: https://github.com/id-Software/Quake-III-Arena https://github.com/id-Software/Quake-III-Arena
- clarry 13y ago
  In my book bloat and performance are two entirely different things, and I think there is a strong correlation between code size and bloat. I agree about highly optimized code being typically larger than the simpler alternative. Now nginx has interesting optimizations in some places (e.g. the http parser), but if you read the code, it's not like 90% of the code in nginx is there due to optimization. I'd like to add that from an OpenBSD perspective, excess optimizations would no doubt be considered bloat as well. One of the goals is that the code is clean, correct, and secure. I know for a fact that the developers are not going to carefully audit and maintain millions of lines of micro-optimizations. What these might get you is a tick in a hypothetical feature checklist ("performance"). But if another daemon does the job and performs well enough, then that feature is unneeded complexity, hence bloat. Not something you want to include in what aims to be the world's most secure general purpose operating system.