Nginx Is Taking Over the Internet(wired.com)
wired.com
Nginx Is Taking Over the Internet
http://www.wired.com/wiredenterprise/2013/09/nginx/
152 comments
Barry Abrahamson actually responded to a similar critique in the comments:
----
Hi,
Barry Abrahamson here. A bit of context to my comment about the stability of Apache. We started WordPress.com using the Litespeed web server, but decided that we wanted to maintain as much of an open source stack as possible. We looked at lighttpd but had lots of issues with memory usage (leaks?) so we naturally turned to Apache. It worked mostly as expected performance and functionality wise. Keep in mind this was back in the Apache 2.0 days. Our problem was that deploying configuration changes which required a graceful restart under production traffic levels didn't work very well. About 10% of the time it either failed to reload the configuration, Apache stopped responding completely, or connections were dropped. Keep in mind that we were reloading ~1000 machines at once, but 10% is a pretty high failure rate. Yes, I know we could have removed machines from production, reloaded the configuration, and then put them back, but it's slow and error-prone, even if automated.
This is when we started looking at nginx. The nginx configuration reload works as expected all of the time, so that was enough to make us invest more time in the software. The transition was non-trivial since we had thousands of lines of .htaccess files which had to be translated to nginx configs, but it was worth it. Today, nginx is the "Swiss Army Knife" of our software stack. We use it for everything we can. I joke that we would use it as a database server if we could :)
------
As a side note, this may be the first useful comment on a Wired article I've ever seen.
----
Hi,
Barry Abrahamson here. A bit of context to my comment about the stability of Apache. We started WordPress.com using the Litespeed web server, but decided that we wanted to maintain as much of an open source stack as possible. We looked at lighttpd but had lots of issues with memory usage (leaks?) so we naturally turned to Apache. It worked mostly as expected performance and functionality wise. Keep in mind this was back in the Apache 2.0 days. Our problem was that deploying configuration changes which required a graceful restart under production traffic levels didn't work very well. About 10% of the time it either failed to reload the configuration, Apache stopped responding completely, or connections were dropped. Keep in mind that we were reloading ~1000 machines at once, but 10% is a pretty high failure rate. Yes, I know we could have removed machines from production, reloaded the configuration, and then put them back, but it's slow and error-prone, even if automated.
This is when we started looking at nginx. The nginx configuration reload works as expected all of the time, so that was enough to make us invest more time in the software. The transition was non-trivial since we had thousands of lines of .htaccess files which had to be translated to nginx configs, but it was worth it. Today, nginx is the "Swiss Army Knife" of our software stack. We use it for everything we can. I joke that we would use it as a database server if we could :)
------
As a side note, this may be the first useful comment on a Wired article I've ever seen.
I agree with the side note ;)
Coincidentally, you probably could use Nginx as a rudimentary database at least since it can be extended with Lua. You can probably make it function as a database proper by using OpenResty. In fact, there are quite a few modules just for that purpose http://openresty.org/#Components
Coincidentally, you probably could use Nginx as a rudimentary database at least since it can be extended with Lua. You can probably make it function as a database proper by using OpenResty. In fact, there are quite a few modules just for that purpose http://openresty.org/#Components
Apache rocks and is battle tested, the problem for them is that Wordpress is PHP which requires the process model worker for stability because PHP isn't thread safe and developers write shitty code assuming it is.
"...because PHP isn't thread safe and developers write shitty code assuming it is."
http://www.iis-aid.com/articles/my_word/difference_between_p...
"Another option is to configure IIS to use PHP in FastCGI mode which allows PHP processes to be recycled rather than killed off after each PHP request and also allows you to run several PHP processes at once, making PHP much much faster with the added bonus that as it is using the CGI interface there is little or no incompatibility issues with PHP extensions. This is still the fastest way to serve PHP, and is the way the IIS Aid PHP Installer is configured to install PHP on your IIS Environment."
http://www.iis-aid.com/articles/my_word/difference_between_p...
"Another option is to configure IIS to use PHP in FastCGI mode which allows PHP processes to be recycled rather than killed off after each PHP request and also allows you to run several PHP processes at once, making PHP much much faster with the added bonus that as it is using the CGI interface there is little or no incompatibility issues with PHP extensions. This is still the fastest way to serve PHP, and is the way the IIS Aid PHP Installer is configured to install PHP on your IIS Environment."
PHP-FPM is also pretty awesome.
I looked at WordPress code and I don't recall seeing any thread stuff being used at all.
The problem with WP and PHP is not stability, but large, complex and suboptimal code. One of the reasons is because WP supports everything and a kitchen sink, and all the features were just patched over it as time went by.
I run custom PHP applications for thousands of users on Apache without problems. I am using nginx in front of it for KeepAlive and static files, which reduces RAM and CPU usage drastically. And it also makes everything faster for website visitors.
There's nothing wrong using both Apache and nginx, each has its purpose.
The problem with WP and PHP is not stability, but large, complex and suboptimal code. One of the reasons is because WP supports everything and a kitchen sink, and all the features were just patched over it as time went by.
I run custom PHP applications for thousands of users on Apache without problems. I am using nginx in front of it for KeepAlive and static files, which reduces RAM and CPU usage drastically. And it also makes everything faster for website visitors.
There's nothing wrong using both Apache and nginx, each has its purpose.
> I looked at WordPress code and I don't recall seeing any thread stuff being used at all.
You misunderstand. You don't need to write threaded code to write code that can't be used in a threaded environment. Think about using and accessing global or static variables in a threaded host environment vs a prefork process based environment.
PHP devs have adopted the practice of using Apache pre-fork rather than simply fixing their bad code because it hides their mistakes. On top of that, Wordpress being a huge plugin based community, you get tons of poorly written plugins that assume they're running in a single process environment because the authors simply don't know any better.
As far as I can tell, most PHP devs seem to think Apache only has a pre-fork mode; they write lengthy articles about how bad Apache is on memory not realizing the only reason it's that bad is because they're using the oldest and most resource hungry worker mpm. They don't seem to be aware Apache has other worker modules like threaded and evented that don't suck down ram like the prefork model does.
You misunderstand. You don't need to write threaded code to write code that can't be used in a threaded environment. Think about using and accessing global or static variables in a threaded host environment vs a prefork process based environment.
PHP devs have adopted the practice of using Apache pre-fork rather than simply fixing their bad code because it hides their mistakes. On top of that, Wordpress being a huge plugin based community, you get tons of poorly written plugins that assume they're running in a single process environment because the authors simply don't know any better.
As far as I can tell, most PHP devs seem to think Apache only has a pre-fork mode; they write lengthy articles about how bad Apache is on memory not realizing the only reason it's that bad is because they're using the oldest and most resource hungry worker mpm. They don't seem to be aware Apache has other worker modules like threaded and evented that don't suck down ram like the prefork model does.
fcgid ftw
The cognitive load of understanding apache is greater than that of nginx; at least initially. And given that we're talking about people who are already taxed by the cognitive load of running a massively multiuser Wordpress installation...
... which are all fairly lightweight cognitive loads ...
[deleted]
Wordpress running on Apache with mpm-prefork - which is the default out the box - does insane bullshit that can indeed cripple the whole system. I run Wordpress via fcgid with mpm-worker by preference, because that way it's isolated in its own little sandbox to crap all over. Funnily enough, you have to run it that way in nginx too.
tl;dr the claim that Apache was the problem is Marketing Bullshit.
tl;dr the claim that Apache was the problem is Marketing Bullshit.
> Apache with mpm-prefork - which is the default out the box
No, the threaded worker is the default, not the prefork.
No, the threaded worker is the default, not the prefork.
It could be what the distros decide to bundle. I've seen mostly prefork.
Fair point, I've only played with Debian and its decedents, they all default to the threaded worker.
Well I think there's a few things going on here. I can tell you from experience that getting higher load WP sites working well takes a LOT of system memory, especially it seems, when you enable WPMU. It is hard for me to pinpoint one culprit for this, but other high-load PHP applications I've dealt with run just fine in standard apache (no php-fpm+MPM module X junk).
From what I've seen essentially Wordpress is just super heavy and tie that in with a more memory hungry MPM+PHP it quickly leads to Apache lockups. I don't think this is a problem with Apache at all, nor even a PHP problem but simply needing to have lighter-weight PHP applications, otherwise you are going to have to start resorting to tricks to get some good RPS counts out of your configuration.
My end of story: Wordpress is awful to scale in Apache and it's not an Apache problem.
From what I've seen essentially Wordpress is just super heavy and tie that in with a more memory hungry MPM+PHP it quickly leads to Apache lockups. I don't think this is a problem with Apache at all, nor even a PHP problem but simply needing to have lighter-weight PHP applications, otherwise you are going to have to start resorting to tricks to get some good RPS counts out of your configuration.
My end of story: Wordpress is awful to scale in Apache and it's not an Apache problem.
It seems like they left some details out. "It was crashing with specific modules or configuration we were using" would be more accurate. The way it's worded makes Apache sound unstable, which isn't true in my experience & research.
If I remember correctly the details of why Nginx might be better at handling massive amount of clients is that it has event-driven architecture.
If you consider a slow client that consumes 1mb of html in, say, half a minute, an Apache thread(2.0)/process serving him would be effectively locked during this time. And thread/process has a relatively big overhead, both memory and cpu wise. Nginx, on the other hand, would just switch to serving the next client/clients, whos socket is ready (using epoll/select).
If you consider a slow client that consumes 1mb of html in, say, half a minute, an Apache thread(2.0)/process serving him would be effectively locked during this time. And thread/process has a relatively big overhead, both memory and cpu wise. Nginx, on the other hand, would just switch to serving the next client/clients, whos socket is ready (using epoll/select).
Apache has had mpm_worker since the 2.2 days, and now (2.4) has mpm_event, which uses epoll too.
[deleted]
I'm a noob at this system admin stuff but according to my statistics I have gathered, nginx webserver uses 30-50% less of the load than apache.
At first, I poured so much into learning Apache I didn't want to learn this weird obscure Russian alternative but I am sure glad I did.
Under load testing, I can have double the amount of concurrent users without even causing my server to hiccup.
When I was running wordpress and apache in AWS I had to use a costly m1-small instance to maintain the cpu and load needs of apache.
When I made the switch to nginx I doubled the performance and was able to move to a free micro instance in AWS.
In conclusion, moving to nginx saved me money and allowed my server to run more efficiently.
I am a believer in this software. Hopefully, going commercial doesn't ruin it like money usually does.
At first, I poured so much into learning Apache I didn't want to learn this weird obscure Russian alternative but I am sure glad I did.
Under load testing, I can have double the amount of concurrent users without even causing my server to hiccup.
When I was running wordpress and apache in AWS I had to use a costly m1-small instance to maintain the cpu and load needs of apache.
When I made the switch to nginx I doubled the performance and was able to move to a free micro instance in AWS.
In conclusion, moving to nginx saved me money and allowed my server to run more efficiently.
I am a believer in this software. Hopefully, going commercial doesn't ruin it like money usually does.
Just double? I managed to get around 8-10x performance from the same hardware. I do not run Wordpress, though, but my custom PHP code.
As someone who was there early on writing documentation and helping in IRC it's extremely nice to see the article mention how volunteers really got this projects documentation off the ground. Hats off to nginx for sharing that tidbit or to the article author if he researched that independently.
I, for one, really appreciate your work (and anyone else who contributed to docs of course). I remember the days when we had to figure stuff out just by looking at other people's config files. I think I even got some of my earliest SO points just from posting sample nginx configs.
Regardless of your Nginx vs Apache Web server war here, Igor Sysoev contributed to Apache a lot: mod_accel - (first?) reverse proxy, mod_deflate, mod_realip.
Several of the comments here point out that part of the reason Apache gets a bad rep is that PHP forces it to use the process based mpm, which is bad. Does this mean that it would make more sense to use mod_fastcgi+php-fpm than mod_php? If so, why isn't that being done?
In httpd-2.4.x (first released in Jan 2012), the event MPM is already the default on Linux:
https://httpd.apache.org/docs/2.4/mpm.html#defaults
In httpd-2.2.x, however, the default MPM on Linux is prefork, i.e. the "bad" one:
https://httpd.apache.org/docs/2.2/mpm.html#defaults
And those would be the "factory" defaults. Distributions can still put in their own defaults, e.g. Ubuntu 12.04 LTS supplies httpd-2.2.x with the worker MPM.
Anyway, Apache 1.3.x (built-in with something similar to the prefork MPM) + mod_php was the de facto (or only?) way to deploy PHP scripts, as you can just throw the scripts into the htdocs directory and they will just work.
https://httpd.apache.org/docs/2.4/mpm.html#defaults
In httpd-2.2.x, however, the default MPM on Linux is prefork, i.e. the "bad" one:
https://httpd.apache.org/docs/2.2/mpm.html#defaults
And those would be the "factory" defaults. Distributions can still put in their own defaults, e.g. Ubuntu 12.04 LTS supplies httpd-2.2.x with the worker MPM.
Anyway, Apache 1.3.x (built-in with something similar to the prefork MPM) + mod_php was the de facto (or only?) way to deploy PHP scripts, as you can just throw the scripts into the htdocs directory and they will just work.
I was forced to do this to run mod_spdy. Now the webserver can serve all of the script/css files from the front page simultaneously, which is a huge win for load times.
I wonder what is planned for Nginx 2.0
I read somewhere ( The it was suppose to be re-engineered.)
Edit: Here http://www.aosabook.org/en/nginx.html
Edit: Here http://www.aosabook.org/en/nginx.html
Does not surprise me. I use NGINX in unison with Apache and it allows me to get maximum performance out of my $25 Linode VPS plan without having to scale up and spend more money. Definitely the best thing to happen to the Internet since Apache.
Anybody know how important epoll was in helping nginx take off?
A lot of that stuff came from the discussion around the original c10k stuff http://www.kegel.com/c10k.html
[deleted]
Let's see the reasons why the author of nginx would not be accepted into ycombinator :
Strong Russian accent : check
Over 40 years old : check
No revenue stream : check
Strong Russian accent : check
Over 40 years old : check
No revenue stream : check
Would NGINX Inc be the sort of company that would really benefit from ycominbator investment and would be profitable for ycombinator to invest in? We shouldn't assume that being selected for ycombinator is the measure of worth towards which early stage companies should aspire.
Question: Is ngingx good for serving APIs as well. I read lots of places thats its best for serving static contents...I got to serve REST API built using JAVA.. response would not exceed 1KB.. Should I put nginx in front.... short, bursty and highly number of concurrent requests.. Is nginx best-fit for API serving....
nginx is a joy to configure and work with. I like the style of thinking of "OK, I'll run this on port 7001 and just use iptables to forward 80 -> 7001" Lets you run services as non-root, with the exception of the iptables one time setup.
Nginx Plus is a great supplement to nginx, especially for corporate users who need a helping hand with the setup and maintenance of any complex system. Thanks Igor!
At least I now know to pronounce Nginx as "Engine X". Now I won't sound like a fool next time someone asks which web server I'm using.
gunicorn "strongly advises" nginx, so ...
Lets all hope the NSA has not injected back doors into NGINX!
I'll stick with Apache, thanks.
What a ridiculous article title. Generates so much discursive noise and adds nothing to the subject of the article.
I don't know, I thought it was cute. "You mean a botnet? [clicks] Oh, nginx!"
Well, that's exactly it. I thought "oh, hacking and/or botnets?" then read the article and thought "why wasn't that called 'New Russian Server tech gains market share' or something a little less pugilistic?"
OT: Holy crap - 'discursive' is the first non-jargon word I've seen in nearly 10 years that's unfamiliar to me. Thanks for that!
I've found particular mileage in it recently during arguments over the UK porn law. Haven't used it this much since university...
Good to see this get some English language press - I think the only other profile of Igor Sysoev I've seen was a volunteer-translated copy of a Russian language article.
Do you remember the title? Or some keywords to find in online?
Perhaps this: http://mindend.com/index.php/interview-with-the-creator-of-n...
found here: https://en.wikipedia.org/wiki/Igor_Sysoev
"This is an interesting interview with a creator of one of the best web servers out there. The original interview is in Russian and the translation (by google) is fairly difficult to read. I took a crack at writing a better translation and I think this might be a bit better."
found here: https://en.wikipedia.org/wiki/Igor_Sysoev
"This is an interesting interview with a creator of one of the best web servers out there. The original interview is in Russian and the translation (by google) is fairly difficult to read. I took a crack at writing a better translation and I think this might be a bit better."
Thanks, I think that was what I was thinking about too. It's a better article than the Wired one.
This was another one I just googled: http://www.freesoftwaremagazine.com/articles/interview_igor_...
This was another one I just googled: http://www.freesoftwaremagazine.com/articles/interview_igor_...
Thanks.
'Would they have considered obscure Russian software if they hadn’t been able to examine the source code? “Never in a million years,” Prince says. “If it hadn’t been open-source, we wouldn’t have trusted it.”'
And that's how a lot of countries will feel about using proprietary (or even open source) software from US in the future, after all the NSA revelations.
And that's how a lot of countries will feel about using proprietary (or even open source) software from US in the future, after all the NSA revelations.
I think he'd have probably answered the same to 'Would they have considered obscure software if they hadn’t been able to examine the source code?' - the salient points being obscure and closed source, not Russian.
If it's not open-source, I won't use it in a production environment, period. I would never willingly tie myself to something that I have absolutely no control over, and could up and die or change models at any moment.
That is exactly the reason I trust Nginx, and ignore G-WAN [1].
[1] http://gwan.com/faq#license
[1] http://gwan.com/faq#license
I'd never heard of gwan before, but just reading that answer puts it on my permanent shitlist.
Open source software is not same as free software. One needs free software (which is open source, as well as give users complete freedom) to ensure their privacy.
In terms of trust: No. As long as I can get the source, modify it and compile my own version, I'm totally in the green as far as privacy and security are concerned.
There's a lot of reasons to prefer free software over mere open source software, but privacy is none of them.
There's a lot of reasons to prefer free software over mere open source software, but privacy is none of them.
Android is "open source", yet there may be restrictions on your ability to compile and run your copy of the source code on your device. Can you trust the OEMs that they are running the same code as you have a copy of?
[deleted]
I suspect that tech people are less concerned with country of origin that many other industries. I'd like to believe that my experience is generalizable and that as a group we're more of a meritocracy. Perhaps it's due to the diversity of people that we routinely work with?
I suspect you're right, but I don't think we should be patting ourselves on the back.
The legal profession has the bar. Doctors need accreditation. Builders need licenses for their jurisdiction.
But software? It doesn't matter who wrote it or where because bits are just bits, especially when you tread into opensource land.
We're a meritocracy because that's the nature of the industry, not because we're particularly benevolent.
The legal profession has the bar. Doctors need accreditation. Builders need licenses for their jurisdiction.
But software? It doesn't matter who wrote it or where because bits are just bits, especially when you tread into opensource land.
We're a meritocracy because that's the nature of the industry, not because we're particularly benevolent.
There's nothing inherent about the industry that means it has to be that way. We deserve a little credit for not putting artificial barriers in place like other industries have.
Barriers aren't necessary artificial or terrible. Unless you'd like your "doctor" to have no accreditation or training.
I think that basic practicality is far more important than an ethos of meritocracy. Using an outstanding piece of software that is free is hardly a great moral judgement on merit. Picking services based on language, ease of billing, and time zone is hardly a rejection of merit.
I agree with the statement that tech people are less concerned with origin and would add another reason being we understand in the open source world there's nothing stopping a Russian programmer, just as an example, from contributing to Apache (which apparently Igor did). But there are plenty of work environments where it is an issue, namely gov't bureaucracies etc. etc.
I've been following the Nginx development for a while. The geographical origin of Nginx was indeed an issue. A few years back the English documentation was very sparse, if it existed at all. When searching for a specific configuration issue, all you could find where some Russian mailing lists. So it required some bravery if you really want to use Nginx a few years back.
Misleading title. A program written by a Russian isn't necessarily "Russian Software".
Well, when nginx started out it was distinctively russian. As in "not a shred of english doc". Everything you could find about it was russian. If that doesn't make it "russian software", then I don't know what makes russian software.
Software written in Russian?
http://en.wikipedia.org/wiki/Non-English-based_programming_l...
> In English, Algol68's reverent case statement reads case ~ in ~ out ~ esac. In Cyrillic, this reads выб ~ в ~ либо ~ быв.
http://en.wikipedia.org/wiki/Non-English-based_programming_l...
> In English, Algol68's reverent case statement reads case ~ in ~ out ~ esac. In Cyrillic, this reads выб ~ в ~ либо ~ быв.
Misleading title. The Internet doesn't depend on any given web server at all, the web is nought but one of many applications.
Nginx has been added to the OpenBSD base system which means it has been security audited and will someday replace the fork of Apache 1.3 as the primary httpd in OpenBSD.
http://marc.info/?l=openbsd-misc&m=134684032310189&w=2
http://marc.info/?l=openbsd-misc&m=134684032310189&w=2
We already moved to Nginx on OpenBSD before 5.2. It was a nice surprise for us when this happened and, although it's not the bleeding edge Nginx release that's available, it was much appreciated since that meant upgrades wouldn't be as difficult from then on.
I should mention that Apache had been good to us in the past, despite being the 1.3 series with patches bundled with OpenBSD, but we were expecting far more from it than it was originally intended to do. In that regard, configuration and deployment became much simpler since we moved to Nginx.
I should mention that Apache had been good to us in the past, despite being the 1.3 series with patches bundled with OpenBSD, but we were expecting far more from it than it was originally intended to do. In that regard, configuration and deployment became much simpler since we moved to Nginx.
Went to nginx on OpenBSD myself, mostly because at some point the latest lighttpd was not playing well with the latest OpenSSL. Never looked back since.
One of our clients had an issue with lighttpd and OpenSSL, but that was on Debian. Turns out it was a known issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622733
You may have seen the same or related problem, since it takes a bit while for packages to come to OpenBSD. But either way, you ended up with something that worked well :)
You may have seen the same or related problem, since it takes a bit while for packages to come to OpenBSD. But either way, you ended up with something that worked well :)
A long time ago the development of apache walks into a wrong direction. Apache get fat and slow.
For now nginx is first choice for Webperformance, but in some years the next thing will arrive.
For now nginx is first choice for Webperformance, but in some years the next thing will arrive.
Apache isn't dead, nor slow, nor going anywhere. As a pluggable module based server, new worker modules will ensure it keeps up just fine.
The difference is actually pretty massive.
See http://wiki.dreamhost.com/Web_Server_Performance_Comparison for instance.
See http://wiki.dreamhost.com/Web_Server_Performance_Comparison for instance.
That's a completely invalid and biased test. They forced Apache into it's worst scaling mpm module, the process based model, which by the way is not the default, and then conclude Apache doesn't scale as well after intentionally breaking it. Lies lies and damn lies.
Aka the mode you have to use if you don't want PHP to blow up.
It's not Apache's fault PHP sucks. Use a better language and Apache works fine with a modern worker module. The issue here is not Apache, it's PHP.
PHP's market share has only been going up (at least over the past three years) and currently sits at about 80% of all server-side programming languages, by at least one count. [0]
[0] http://w3techs.com/technologies/history_overview/programming...
[0] http://w3techs.com/technologies/history_overview/programming...
[deleted]
But the point is Nginx lets you have your cake and eat it too....no issues with PHP and fast performance and less memory usage.
But Nginx is not running the PHP code, whatever the application daemon on the background does. Nginx simply proxies to it. Apache can get similar performance if you offload PHP and not use the mod_php.
That's great, but it's got nothing to do with Apache. If you choose a shitty language, and PHP is shitty no matter how popular it gets, you're limited in choices elsewhere. There's clearly a market for Nginx, low memory virtual servers running PHP. Remove PHP and use a better language and Apache scale just fine even in low memory conditions because without PHP, you don't have to use the old fashioned process model. Apache can work with PHP-FPM just like Nginx using the new evented worker mpm, but as PHP devs clearly find Apache confusing there's no reason to bother.
> without PHP, you don't have to use the old fashioned process model.
Immediately followed by:
> Apache can work with PHP-FPM just like Nginx using the new evented worker mpm
seems contradictory. Can you clarify this bit?
Immediately followed by:
> Apache can work with PHP-FPM just like Nginx using the new evented worker mpm
seems contradictory. Can you clarify this bit?
The Apache evented worker is very new, just out in 2.4, so it's still standard practice to use the process model. The new way should bring it inline with Nginx but it's too new to say if it's as stable as Nginx; at least for me to say it.
There are now three major MPMs:
Prefork - if you want to use mod_php, you're stuck with this. I think this is what you're referring to as "the process model"
Worker - Uses threads to handle connections. A big step up from prefork, but not as awesomesauce as nginx.
Evented - The new MPM which use epoll
It's been possible to run PHP(-fpm) under "worker" (via FastCGI) for years, and it performs adequately. I never benchmarked, but I was using this setup back when nginx was still too bleeding-edge for my tastes, and it certainly beat the pants of prefork/mod_php
Prefork - if you want to use mod_php, you're stuck with this. I think this is what you're referring to as "the process model"
Worker - Uses threads to handle connections. A big step up from prefork, but not as awesomesauce as nginx.
Evented - The new MPM which use epoll
It's been possible to run PHP(-fpm) under "worker" (via FastCGI) for years, and it performs adequately. I never benchmarked, but I was using this setup back when nginx was still too bleeding-edge for my tastes, and it certainly beat the pants of prefork/mod_php
Switch PHP to FastCGI under Apache (as it is under nginx), and this isn't a problem.
I did not say that apache is dead. I use it since over 10 years on many servers, but i use it today because of historical reasons.
I use nginx too and see the difference. There is a place for apache, but not the leadership of webservers.
I use nginx too and see the difference. There is a place for apache, but not the leadership of webservers.
For my style of coding, and I think many others, Nginx has become dominant because it enables fast reverse proxy. And I think for many large websites it ahs become common to build websites out of many small apps, which run on different ports and which Nginx then knits together.
An example. Assuming you have the domain “example.com” then you might have an app that handles user login and you spin that up on, say, port 30000 and you map it to port 80 such that is appears as:
http://www.example.com/login
You might also have an app that handles user signups which you spin up on port 30001 and you map to port 80 such that it appears as:
http://www.example.com/signup
You might also have an admin app that you spin up on port 30002 and you map to
http://admin.example.com/
You might also have an app that allows users to update their profile information and you spin that up on port 30003 and map that to
http://www.example.com/profile
And you might have an app that publishes much of your content as static HTML files, which you spin up on no port, as it does not accept TCP/IP requests — instead it queries the database and then creates static html files, which you save to some directory such as /var/www/example.com/public_html/ and you map that to
http://www.example.com/
You can see how this gives the sysadmins a lot of freedom to spread load across servers in creative ways — if 1 app becomes especially popular, or resource hungry, the sysadmins can rather easily move it to its own server (or set of servers). This is one of the main reasons most big sites move to an architecture like this — it facilitates fine grained control of what sort of requests go to a particular server.
This is a flexible style and it allows small, maintainable apps. By contrast, consider web development circa 2001, when many people felt it was enough to put a big blob of PHP in a directory and let Apache serve it as one big app.
Nginx's fast reverse proxy allows developers to focus on building their apps, without having to worry too much the server details. It also offers a cleaner separation between concerns that should worry programmers and concerns that should worry the sysadmins.
(A final point: in my own apps, for information that needs to be shared quickly across apps, like which users are logged in, I use ZeroMQ to knit the apps together.)
An example. Assuming you have the domain “example.com” then you might have an app that handles user login and you spin that up on, say, port 30000 and you map it to port 80 such that is appears as:
http://www.example.com/login
You might also have an app that handles user signups which you spin up on port 30001 and you map to port 80 such that it appears as:
http://www.example.com/signup
You might also have an admin app that you spin up on port 30002 and you map to
http://admin.example.com/
You might also have an app that allows users to update their profile information and you spin that up on port 30003 and map that to
http://www.example.com/profile
And you might have an app that publishes much of your content as static HTML files, which you spin up on no port, as it does not accept TCP/IP requests — instead it queries the database and then creates static html files, which you save to some directory such as /var/www/example.com/public_html/ and you map that to
http://www.example.com/
You can see how this gives the sysadmins a lot of freedom to spread load across servers in creative ways — if 1 app becomes especially popular, or resource hungry, the sysadmins can rather easily move it to its own server (or set of servers). This is one of the main reasons most big sites move to an architecture like this — it facilitates fine grained control of what sort of requests go to a particular server.
This is a flexible style and it allows small, maintainable apps. By contrast, consider web development circa 2001, when many people felt it was enough to put a big blob of PHP in a directory and let Apache serve it as one big app.
Nginx's fast reverse proxy allows developers to focus on building their apps, without having to worry too much the server details. It also offers a cleaner separation between concerns that should worry programmers and concerns that should worry the sysadmins.
(A final point: in my own apps, for information that needs to be shared quickly across apps, like which users are logged in, I use ZeroMQ to knit the apps together.)
Dude, what are you rambling about? The same can be achieved in Apache with 2 config lines.
Nginx has taken over some of Apache's market because it's lighter on resources, i.e. with the same amount of resources it can process & deliver more stuff.
Regarding functionality and configuration there is not much difference, actually I think Apache still has the edge here.
Nginx has taken over some of Apache's market because it's lighter on resources, i.e. with the same amount of resources it can process & deliver more stuff.
Regarding functionality and configuration there is not much difference, actually I think Apache still has the edge here.
>Nginx has taken over some of Apache's market because it's lighter on resources, i.e. with the same amount of resources it can process & deliver more stuff.
That's precisely why we moved to Nginx. We do mostly Java so Apache was not the problem there, as it was simply proxying over to Jettys.
But the blog is wordpress that means PHP, so we had to use modphp modules with Apache. That was Okay initially, but as we scaled, we saw some 50 instances of Apache and each taking 25 Mb memory. And note, most of the bloat in memory was due to modphp being loaded in-memory in each instance.
We moved to Nginx with an external php-fpm for PHP, and just 4 Nginx instances take up the entire load and each uses some 2.5 Mb of memory.
And at the same time Google webmaster shows a significant drop in average latency.
So that's our experience of why we moved to Nginx.
Edit: typo
That's precisely why we moved to Nginx. We do mostly Java so Apache was not the problem there, as it was simply proxying over to Jettys.
But the blog is wordpress that means PHP, so we had to use modphp modules with Apache. That was Okay initially, but as we scaled, we saw some 50 instances of Apache and each taking 25 Mb memory. And note, most of the bloat in memory was due to modphp being loaded in-memory in each instance.
We moved to Nginx with an external php-fpm for PHP, and just 4 Nginx instances take up the entire load and each uses some 2.5 Mb of memory.
And at the same time Google webmaster shows a significant drop in average latency.
So that's our experience of why we moved to Nginx.
Edit: typo
I hear this a lot about Apache and there's one thing I'm not sure a lot of people understand... it's SHARED memory in most cases. While it spawns several processes (depending on which worker method), it's not as awful as it looks at first glance.
A quick google search finds a nitty gritty page that might help - http://foertsch.name/ModPerl-Tricks/Measuring-memory-consump... there's probably better examples.
Yes nginx does have lower memory usage, but on most non vps/shared servers this is a lot less of a concern than most people think vs Apache.
php-fm works great with Apache as well and probably accounts for the huge resource gain over mod_php that Apache uses by default.
A quick google search finds a nitty gritty page that might help - http://foertsch.name/ModPerl-Tricks/Measuring-memory-consump... there's probably better examples.
Yes nginx does have lower memory usage, but on most non vps/shared servers this is a lot less of a concern than most people think vs Apache.
php-fm works great with Apache as well and probably accounts for the huge resource gain over mod_php that Apache uses by default.
I hear this a lot about Apache and there's one thing I'm not sure a lot of people understand... it's SHARED memory in most cases. While it spawns several processes (depending on which worker method), it's not as awful as it looks at first glance.
Apache, and specifically mod_php, doesn't have that level of control over memory usage (mod_perl (and, incidentally, mod_python) has deeper integration with Apache to encourage, with the right configuration, more of the memory to be shared between processes, but it's still not that great). The Apache parent process, primarily exists to do process, signal, and socket management, it's not really possible to do a lot of application level (pre)processing before subprocesses are forked off, which is what would be required to share a significant portion of the address space.
If you have a .php file run via mod_php that looks like this:
A quick google search finds a nitty gritty page that might help - http://foertsch.name/ModPerl-Tricks/Measuring-memory-consump.... there's probably better examples.
That is a great link in general for how shared memory and COW works.
Apache, and specifically mod_php, doesn't have that level of control over memory usage (mod_perl (and, incidentally, mod_python) has deeper integration with Apache to encourage, with the right configuration, more of the memory to be shared between processes, but it's still not that great). The Apache parent process, primarily exists to do process, signal, and socket management, it's not really possible to do a lot of application level (pre)processing before subprocesses are forked off, which is what would be required to share a significant portion of the address space.
If you have a .php file run via mod_php that looks like this:
$x="";
for ($a=0;$a<(1024*1024*100);$a++) {
$x.="1";
}
A quick google search finds a nitty gritty page that might help - http://foertsch.name/ModPerl-Tricks/Measuring-memory-consump.... there's probably better examples.
That is a great link in general for how shared memory and COW works.
So you've moved the memory usage from the web server proper to the external php-fpm processes, which are most likely getting recycled more frequently than the default settings for apache prefork workers are so you're not seeing the ballooning PHP memory usage. The size of the 50 instances of Apache each taking 25 meg is most likely because of the PHP code and mod_php, not because of Apache itself.
Agreed. In hindsight, I am sure, we could have externalized the PHP with Apache as well. But the larger context of this move was doing more with less. And Nginx just working with 4 instances and serving just as much, with a reduced average latency of page load, justified the move.
And I sort of felt sad doing this. Because I have a huge respect for Apache. I hope just like what Chrome did to Firefox, Nginx does to Apache, and its a win-win for all.
And I sort of felt sad doing this. Because I have a huge respect for Apache. I hope just like what Chrome did to Firefox, Nginx does to Apache, and its a win-win for all.
But the larger context of this move was doing more with less. And Nginx just working with 4 instances and serving just as much, with a reduced average latency of page load, justified the move.
"More with less" here is a judgement call. You've increased the number of processes and subsystems that need to be managed (nginx + php_fpm), which is more. You've increased the context switching when dynamic requests need to be passed to another process and proxied through nginx. The communication between the frontend web server and php_fpm needs to be serialized in some fashion, so you're now incurring a greater than 1x cost in processing and parsing things like HTTP headers and the request (serializing and deserializing the data to pass that between the processes). It seems you're ignoring the actual cost of running dynamic PHP code because the cost has been moved out of the "web server", the thing that listens on port 80, and into something that isn't considered "a web server", but this is just a change in bookkeeping.
Do you know where that reduced average latency is coming from? Is it because nginx is serving static assets that would tie up an apache worker that could be running/serving PHP in apache? If so, you can do the same thing by offloading all your static asset serving to another server (or a completely external CDN, which has other extremely beneficial client-side advantages too) using apache too. That is, the choice of software here isn't as big a win as presented, it's the architecture of the ecosystem that is the big influence.
It's great that you found something that works better for your workload, and it's appropriate to use what works and not get bogged down in why all the time. But the way you've presented it doesn't indicate well that all the causes and effects are completely understood. And I think this ends up giving Apache a bad rap.
"More with less" here is a judgement call. You've increased the number of processes and subsystems that need to be managed (nginx + php_fpm), which is more. You've increased the context switching when dynamic requests need to be passed to another process and proxied through nginx. The communication between the frontend web server and php_fpm needs to be serialized in some fashion, so you're now incurring a greater than 1x cost in processing and parsing things like HTTP headers and the request (serializing and deserializing the data to pass that between the processes). It seems you're ignoring the actual cost of running dynamic PHP code because the cost has been moved out of the "web server", the thing that listens on port 80, and into something that isn't considered "a web server", but this is just a change in bookkeeping.
Do you know where that reduced average latency is coming from? Is it because nginx is serving static assets that would tie up an apache worker that could be running/serving PHP in apache? If so, you can do the same thing by offloading all your static asset serving to another server (or a completely external CDN, which has other extremely beneficial client-side advantages too) using apache too. That is, the choice of software here isn't as big a win as presented, it's the architecture of the ecosystem that is the big influence.
It's great that you found something that works better for your workload, and it's appropriate to use what works and not get bogged down in why all the time. But the way you've presented it doesn't indicate well that all the causes and effects are completely understood. And I think this ends up giving Apache a bad rap.
>Do you know where that reduced average latency is coming from? Is it because nginx is serving static assets that would tie up an apache worker that could be running/serving PHP in apache? If so, you can do the same thing by offloading all your static asset serving to another server (or a completely external CDN, which has other extremely beneficial client-side advantages too) using apache too. That is, the choice of software here isn't as big a win as presented, it's the architecture of the ecosystem that is the big influence.
Yes, I understand that. I have studied about the C10K problem[1]. And have coded another service which just uses libevent[2] directly and some C++ code to serve a feature for our site very low latency. So I understand quite well why Nginx is offering low latency.
As you rightly observe later on, I don't have the luxury to get obsessed with all the Whys, so often shoot for the major architectural gain and take any side effects that come along in the stride.
>.. But the way you've presented it doesn't indicate well that all the causes and effects are completely understood. And I think this ends up giving Apache a bad rap.
I am surprised by your this observation. I have been 100% honest in what I wrote above, and I repeat have a huge respect and thankful for the Apache team and Apache web server software. Just that, by the page loading gains we got, were clearly very good. And also there were less errors in general reported in the web master. So we stuck with the change.
Also a point regarding the switching costs and extra processing between php-fpm and Nginx processes. As I said in my first comment, we do mainly Java and PHP is just for the blog. But I very clearly remember seeing all the Apache child procs bloating to 25 Mb after the first hit to the PHP code was done. So I am actually saving by externalizing on the resources. Trust me I know what I am doing.
Another tangential thing not related to Nginx, which I am doing for low resource consumption. Is moving some relevant code from Java to Go. And there also am seeing huge memory gains (i.e. savings). Perhaps will share more about it at an appropriate time.
[1] http://www.kegel.com/c10k.html
[2] libevent.org
Edit: grammar
Yes, I understand that. I have studied about the C10K problem[1]. And have coded another service which just uses libevent[2] directly and some C++ code to serve a feature for our site very low latency. So I understand quite well why Nginx is offering low latency.
As you rightly observe later on, I don't have the luxury to get obsessed with all the Whys, so often shoot for the major architectural gain and take any side effects that come along in the stride.
>.. But the way you've presented it doesn't indicate well that all the causes and effects are completely understood. And I think this ends up giving Apache a bad rap.
I am surprised by your this observation. I have been 100% honest in what I wrote above, and I repeat have a huge respect and thankful for the Apache team and Apache web server software. Just that, by the page loading gains we got, were clearly very good. And also there were less errors in general reported in the web master. So we stuck with the change.
Also a point regarding the switching costs and extra processing between php-fpm and Nginx processes. As I said in my first comment, we do mainly Java and PHP is just for the blog. But I very clearly remember seeing all the Apache child procs bloating to 25 Mb after the first hit to the PHP code was done. So I am actually saving by externalizing on the resources. Trust me I know what I am doing.
Another tangential thing not related to Nginx, which I am doing for low resource consumption. Is moving some relevant code from Java to Go. And there also am seeing huge memory gains (i.e. savings). Perhaps will share more about it at an appropriate time.
[1] http://www.kegel.com/c10k.html
[2] libevent.org
Edit: grammar
I am surprised by your this observation. I have been 100% honest in what I wrote above... Trust me I know what I am doing.
Sorry, I didn't mean to suggest that you weren't being honest or that you didn't know what you were doing.
I'm sure we've all had to deal with "Well, this guy on HN converted to X from Y and saw <insert generic gains claims here>, so why are we on Y again?", which the somewhat hand-wavy details in your original comment can end up contributing to (obviously we're limited for space and attention here, so leaving out some details can be desirable). What I failed at was communicating that my comments were not intended as an attack on your specific methodologies or choices, but was more meant to make the reader of our comments consider the wider implications of blindly following the herd and not making informed decisions. I have had people forward me lists of links to isolated, comment-less HN comments as "support" for their position.
But I very clearly remember seeing all the Apache child procs bloating to 25 Mb after the first hit to the PHP code was done. So I am actually saving by externalizing on the resources.
Yes, sorry, I didn't consider the exact traffic ratios between the (proxied) Java requests and the (internally handled) PHP requests. If you've got a wide spread there favoring proxied requests, then, as you've experienced, it would be advantageous to get rid of the internal handling, proxy all requests, and outsource the bloating to other processes/systems where it is more isolated, and the upper bound on the bloat be more influenced by the lower total requests for the resources that consume more. And once that's done (the getting rid of the monolithic parts) then it's a lot easier to experiment with replacing the different parts to see if there are other gains. You may have seen similar resource consumption benefits by nginx proxying to Apache+mod_php or even to bare PHP cgi.
But one shouldn't even follow that method blindly either, because it's all based on workload, and everyone's workload is different.
There are so system management and monitoring benefits and drawbacks that go with these kinds of changes. We both know that there is no software selection silver bullet, but it's not necessarily the readers of these comments that know that.
Sorry, I didn't mean to suggest that you weren't being honest or that you didn't know what you were doing.
I'm sure we've all had to deal with "Well, this guy on HN converted to X from Y and saw <insert generic gains claims here>, so why are we on Y again?", which the somewhat hand-wavy details in your original comment can end up contributing to (obviously we're limited for space and attention here, so leaving out some details can be desirable). What I failed at was communicating that my comments were not intended as an attack on your specific methodologies or choices, but was more meant to make the reader of our comments consider the wider implications of blindly following the herd and not making informed decisions. I have had people forward me lists of links to isolated, comment-less HN comments as "support" for their position.
But I very clearly remember seeing all the Apache child procs bloating to 25 Mb after the first hit to the PHP code was done. So I am actually saving by externalizing on the resources.
Yes, sorry, I didn't consider the exact traffic ratios between the (proxied) Java requests and the (internally handled) PHP requests. If you've got a wide spread there favoring proxied requests, then, as you've experienced, it would be advantageous to get rid of the internal handling, proxy all requests, and outsource the bloating to other processes/systems where it is more isolated, and the upper bound on the bloat be more influenced by the lower total requests for the resources that consume more. And once that's done (the getting rid of the monolithic parts) then it's a lot easier to experiment with replacing the different parts to see if there are other gains. You may have seen similar resource consumption benefits by nginx proxying to Apache+mod_php or even to bare PHP cgi.
But one shouldn't even follow that method blindly either, because it's all based on workload, and everyone's workload is different.
There are so system management and monitoring benefits and drawbacks that go with these kinds of changes. We both know that there is no software selection silver bullet, but it's not necessarily the readers of these comments that know that.
Let's consider boxcars also: http://github.com/azer/boxcars
People have been and still do exactly the same thing with Apache, this isn't unique to Nginx in any way.
Except the configuration is far simpler with Nginx. What's more, you can even couple this with upstream weighted loadbalancing or round-robin which is terribly awkward without modules on Apache.
Edit: Not to mention sticky sessions per proxy which simplifies user management.
Edit: Not to mention sticky sessions per proxy which simplifies user management.
Simpler, yes, that doesn't make Apache complicated. They're all simple. To say without modules makes no sense, modules are how Apache does features and the mod balance module makes all of that simple including sticky sessions. If you can write code, you can configure Apache easily.
"Simpler, yes, that doesn't make Apache complicated. They're all simple."
Didn't you just contradict yourself? How can it be simpler and all be simple? Simpler implies one is greater in simplicity so which is it?
FWIW, we were running Apache 1.3 with patches on OpenBSD. For us, using the 2.x branch wasn't possible without staying atop the modules for code issues/vulnerabilities. Considering other client expectations, we didn't have the resources to audit everything like that. The fact that OpenBSD 5.2 included Nginx by default was a nice plus for us too, but we started the move before then.
Didn't you just contradict yourself? How can it be simpler and all be simple? Simpler implies one is greater in simplicity so which is it?
FWIW, we were running Apache 1.3 with patches on OpenBSD. For us, using the 2.x branch wasn't possible without staying atop the modules for code issues/vulnerabilities. Considering other client expectations, we didn't have the resources to audit everything like that. The fact that OpenBSD 5.2 included Nginx by default was a nice plus for us too, but we started the move before then.
> Didn't you just contradict yourself?
No, I did not.
> How can it be simpler and all be simple? Simpler implies one is greater in simplicity so which is it?
Is English not your first language? I can choose 5 simple things, and then compare them to each other and say one is simpler. They're all still simple.
> FWIW, we were running Apache 1.3 with patches on OpenBSD. For us, using the 2.x branch wasn't possible without staying atop the modules for code issues/vulnerabilities.
Sounds like your OS was the real culprit for not keeping up with newer releases. Again, if Nginx works for you, great, you can promote that without putting down Apache which is quite simple and rock solid stable as well.
No, I did not.
> How can it be simpler and all be simple? Simpler implies one is greater in simplicity so which is it?
Is English not your first language? I can choose 5 simple things, and then compare them to each other and say one is simpler. They're all still simple.
> FWIW, we were running Apache 1.3 with patches on OpenBSD. For us, using the 2.x branch wasn't possible without staying atop the modules for code issues/vulnerabilities.
Sounds like your OS was the real culprit for not keeping up with newer releases. Again, if Nginx works for you, great, you can promote that without putting down Apache which is quite simple and rock solid stable as well.
'm not a native English speaker, but I might as well be because of my proficiency. The way you formulated those two sentences was a bit off putting for me, too.
There was no need to be rude.
There was no need to be rude.
Insulting me is a pretty poor way of being persuasive. And English is my first language, thank you.
As someone who's apparently more fluent than I am in English, you should have noted that I'm not "putting down" Apache as much as showing that, out of the box, Nginx still is a better option than Apache. This isn't my opinion as much as it is empirically observed fact both in our environment as well as our clients' environments.
As someone who's apparently more fluent than I am in English, you should have noted that I'm not "putting down" Apache as much as showing that, out of the box, Nginx still is a better option than Apache. This isn't my opinion as much as it is empirically observed fact both in our environment as well as our clients' environments.
> Insulting me is a pretty poor way of being persuasive.
I didn't insult you, it was an honest question as I can't assume everyone here is a native English speaker and your confusion could have easily been a language thing.
> And English is my first language, thank you.
OK, great, then I don't know what was at all confusing about what I said.
> Apache as much as showing that, out of the box, Nginx still is a better option than Apache.
Such blanket statements are simply unsupportable. It depends entirely on the workload, needs, language, and configuration. Out of the box, Apache isn't configured for the process model that everyone complains makes it a pig.
I didn't insult you, it was an honest question as I can't assume everyone here is a native English speaker and your confusion could have easily been a language thing.
> And English is my first language, thank you.
OK, great, then I don't know what was at all confusing about what I said.
> Apache as much as showing that, out of the box, Nginx still is a better option than Apache.
Such blanket statements are simply unsupportable. It depends entirely on the workload, needs, language, and configuration. Out of the box, Apache isn't configured for the process model that everyone complains makes it a pig.
You have been downvoted, lol.
This is the stupid HN system at work: Someone who doesn't understand English being a native speaker (simple vs simpler) can downvote you because he has "earned" that right, by submitting a gazillion articles with 1 point each.
This is the stupid HN system at work: Someone who doesn't understand English being a native speaker (simple vs simpler) can downvote you because he has "earned" that right, by submitting a gazillion articles with 1 point each.
I didn't downvote anyone on this thread. In fact, you can't downvote anyone who has replied to you or anyone you're replying to you. Article submissions are for everyone to read whether they're voted for or not. I frequently browse /newest because I see articles that never make the front page, that I enjoy regardless and I want to share what I find interesting.
While you're here, you may want to take a browse on the guidelines http://ycombinator.com/newsguidelines.html
While you're here, you may want to take a browse on the guidelines http://ycombinator.com/newsguidelines.html
>Sounds like your OS was the real culprit for not keeping up with newer releases.
Newer releases are quite bad from both a security and a stability standpoint. They did not make configuration simpler, so the idea that using the last reasonable release of apache was the problem doesn't make any sense.
Newer releases are quite bad from both a security and a stability standpoint. They did not make configuration simpler, so the idea that using the last reasonable release of apache was the problem doesn't make any sense.
Where's the contradiction? He says that Nginix is simpler than Apache, which is also simple.
"which is it?"
He just said which one it was. I don't see how anyone could fail to understand this.
"which is it?"
He just said which one it was. I don't see how anyone could fail to understand this.
> How can it be simpler and all be simple? Simpler implies one is greater in simplicity so which is it?
Two feet is not very far to walk. Three feet is farther, but it is still not a great distance to walk. Two things can both be short/simple even if one is a bit shorter/simpler.
Two feet is not very far to walk. Three feet is farther, but it is still not a great distance to walk. Two things can both be short/simple even if one is a bit shorter/simpler.
There's no contradiction in his/her statement. You are just being obtuse
Either Nginx and Apache is pain in the ass to configure. No need to mention both have some unix challenges that you gotta solve for just starting to serve bunch of stupid shit. Have a look at boxcars
I installed Apache recently along with ownCloud on my Raspberry Pi. I had to strip it back out when I realized that Apache worker processes were keeping the CPU and RAM at 100% the entire time, when nothing was even connected to it.
I used to use Apache all the time way back when. The memories that stick with me are of a massive tangle of configuration rules, mod_*, and htaccess files. I've never looked back since going the way of Nginx. It's just so lightweight in comparison, both performance- and maintenance-wise.
I used to use Apache all the time way back when. The memories that stick with me are of a massive tangle of configuration rules, mod_*, and htaccess files. I've never looked back since going the way of Nginx. It's just so lightweight in comparison, both performance- and maintenance-wise.
That a bug. Probably an architecture dependant one or some package maintainer who messed up. Your experience with Apache httpd on your little homebrew computer gadget doesn't say anything about Apache httpd and how it is usually deployed.
Apache httpd is still bloody awesome.
Apache httpd is still bloody awesome.
As stated in the same comment, my "little homebrew computer gadget" wasn't the only platform I've run Apache httpd on. It was just yet another environment in which it came out as sub-optimal when compared with Nginx in the same use case.
Let me explain you what buggy means. Buggy means heavy, overweight, with thousands of configuration lines just to end up with something slow and crashing.
I don't think it's fair to use the rPi as your case-study. You would be hard-pressed to find a complete modern computer that is more different from the typical machine that runs httpd in a commercial environment.
As I said, the Raspberry Pi isn't the only platform I've run Apache httpd on, and that experience isn't the primary motivating factor behind my dislike for the software.
It just struck me how starkly the difference in resource consumption between it and Nginx was illustrated in that case in particular, as the rPi handles the latter just fine.
It just struck me how starkly the difference in resource consumption between it and Nginx was illustrated in that case in particular, as the rPi handles the latter just fine.
Sounds like something isn't right. You might have a setup where everything is enabled (at least from a high memory consumption point of view). You can get the Apache child processes down to ~2MiB (still a bit high by lighttpd and nginx standards) by disabling a lot of the modules. How many child processes started by default? Check your mpm settings, as you could be using the configuration for a beefy server environment.
He did start his comment with "For my style of coding". Maybe it's just simpler to configure these rules in Nginx than it is in Apache for lkrubner.
The problem is that he says Nginx enabled fast reverse proxy and that's just not true, nothing he described was enabled by Nginx, that was how people already did things in Apache. Apache is not hard to configure, it would support his style of coding just fine and very likely work just as well as Nginx for him.
The problem people have with Apache usually isn't really apache, it's with PHP forcing them to use the process based mpm which makes it a pig. This is PHP's fault, not Apache's. use the threaded or evened worker mpm's and it's not a pig at all.
The problem people have with Apache usually isn't really apache, it's with PHP forcing them to use the process based mpm which makes it a pig. This is PHP's fault, not Apache's. use the threaded or evened worker mpm's and it's not a pig at all.
Yes. It is remarkably simple to set up reverse proxies in nginx.
It is also remarkably easy to set up SSL (minus generating certificates) -- it's only 3 lines.
It is also remarkably easy to set up SSL (minus generating certificates) -- it's only 3 lines.
It's just as easy in Apache.
...No it isn't. It might be 'simple' for you, and it might be readily configurable once you know how to do it, but that doesn't make it easy.
I really can't tell if you're being deliberately obtuse about this. Don't you see all the people going "Yeah, it was faster to do this with nginx than it was with Apache"?
Are you the sort of person that's surprised PHP got so popular?
I really can't tell if you're being deliberately obtuse about this. Don't you see all the people going "Yeah, it was faster to do this with nginx than it was with Apache"?
Are you the sort of person that's surprised PHP got so popular?
Oh, come on. It's pretty simple. You google a bit around for it and find some 3 year old blog post that tells you what to do. You'd probably have to do the same for nginx anyway.
I prefer nginx' configuration syntax over apache's though.
I prefer nginx' configuration syntax over apache's though.
I'd like to point out that my first point was specifically towards reverse proxying...
This page should be all the proof I need: http://www.apachetutor.org/admin/reverseproxies
where as reverse proxies in nginx: http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.h...
So maybe you could make a case for nginx being less modular (or obviously so) -- but 1 config files with the right magic spell beats downloading x module and setting up x directory PLUS the magic file.
Also, I think that in general, nginx fits more into the many-apps-different-implementations-same-server vision of the modern day web app.
This page should be all the proof I need: http://www.apachetutor.org/admin/reverseproxies
where as reverse proxies in nginx: http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.h...
So maybe you could make a case for nginx being less modular (or obviously so) -- but 1 config files with the right magic spell beats downloading x module and setting up x directory PLUS the magic file.
Also, I think that in general, nginx fits more into the many-apps-different-implementations-same-server vision of the modern day web app.
That would be pretty bad proof though. If you ignore the chit-chat, which is just the authors writing style, and the ugly colour scheme, the essential part is here: http://www.apachetutor.org/admin/reverseproxies#d13
That's 26 lines of configuration, compared to the nginx example, which is 54 lines. Both are kind of arcane looking, if you haven't used it before.
That's 26 lines of configuration, compared to the nginx example, which is 54 lines. Both are kind of arcane looking, if you haven't used it before.
oh but what about installing the modules/files that are getting loaded?
True, they're not night and day, but it's still stuff to do. Also, the page I sent, the actual reverse proxy is only 14 lines, half of it is extra stuff... The section where it says "start with example.com".
And that's the whole server, whereas the
True, they're not night and day, but it's still stuff to do. Also, the page I sent, the actual reverse proxy is only 14 lines, half of it is extra stuff... The section where it says "start with example.com".
And that's the whole server, whereas the
... hahaha exactly.
I didn't say it wasn't simple. But simple is just sufficiently managed complexity.
I didn't say it wasn't simple. But simple is just sufficiently managed complexity.
> Don't you see all the people going "Yeah, it was faster to do this with nginx than it was with Apache"?
Configuring Apache is easy as there are tens of thousands of tutorials showing you exactly how to add those two little lines of code to enable proxy and/or a cert. Both Apache and Nginx are easy to configure, Nginx is easier, that doesn't make Apache hard.
> Are you the sort of person that's surprised PHP got so popular?
Nope, I've worked with tons of PHP developers and I know exactly why it's popular. Wide support, easy copy to server deployment, and in large part, dumber programmers who want you to give them the codes because it's a copy and paste community in large part. All languages have a wide variety of users, but I've found the worst of the worst go to PHP like a month to a flame exactly because it's so simple to get started and despite how terrible a language it is.
Configuring Apache is easy as there are tens of thousands of tutorials showing you exactly how to add those two little lines of code to enable proxy and/or a cert. Both Apache and Nginx are easy to configure, Nginx is easier, that doesn't make Apache hard.
> Are you the sort of person that's surprised PHP got so popular?
Nope, I've worked with tons of PHP developers and I know exactly why it's popular. Wide support, easy copy to server deployment, and in large part, dumber programmers who want you to give them the codes because it's a copy and paste community in large part. All languages have a wide variety of users, but I've found the worst of the worst go to PHP like a month to a flame exactly because it's so simple to get started and despite how terrible a language it is.
I think of PHP as a templating language, to be honest. I like it (I still think the LAMP stack is cool), but the kind of code that it forces you to produce is often focused around document generation (as was the majority of the internet for a long time).
Maybe it's just the wrong tool for this time, and it used to be right tool in the past.
Maybe it's just the wrong tool for this time, and it used to be right tool in the past.
It is definately simpler to configure Nginx to reverse proxy, Apache needs a few more lines of configuration.
From http://httpd.apache.org/docs/2.2/mod/mod_proxy.html:
ProxyPass /foo http://foo.example.com/bar ProxyPassReverse /foo http://foo.example.com/bar
I've used it for years, it's not hard.
ProxyPass /foo http://foo.example.com/bar ProxyPassReverse /foo http://foo.example.com/bar
I've used it for years, it's not hard.
I was talking about installing Apache and setting it up as a reverse proxy vs. installing Nginx and setting it up as a reverse proxy. Nginx takes less configuration in that scenario. I've done both and neither are hard, but nginx is slightly easier.
Installing Apache is a single command, enabling mod proxy is a single command and two lines of config. So yes, they are both trivially simple to do, even if Nginx is slightly simpler. Neither should be seen as a barrier of complexity.
For the simple case Apache is only 2 lines. Nginx requires more, because Apache automatically sets the proxy headers and Nginx does not.
This is the reason we use nginx. It can hide the details of our multiple platform architecture.
All the discussion around Nginx recently, has me wondering if I should revisit my own proxy project: http://switchflow.org/
All the discussion around Nginx recently, has me wondering if I should revisit my own proxy project: http://switchflow.org/
I've been using Varnish for this: it's even simpler and has the advantage of having a non-broken HTTP cache module so you can use content negotiation and caching at the same time.
[deleted]
Great summary.
Given Apache's track record and massive deployment, how could this be possible? Isn't it more likely that the Wordpress people were doing something wrong? Not that Nginx isn't great, but I'm bemused by the occasional suggestions I see that it's saving us from the suddenly broken Apache.