Why Use Nginx?
wiki.nginx.org
wiki.nginx.org
(Now this is more of a "Testimonials" page, but for server tech it will do.)
> Apache is like Microsoft Word, it has a million options but you only need six. Nginx does those six things, and it does five of them 50 times faster than Apache.
This is exactly how I felt. I'm a pea-brained dolt in the server sphere, and when I was remaking my server I went with nginx over apache on the advice of a friend because "the config file is easier to understand."
He was right. And instead of being frustrated and bumbling through apache until it worked the way I wanted, I was able to configure nginx (for the first time!) in mere minutes. With nginx I was able to move on to the "get frustrated by Wordpress" phase of server setup much sooner!
Not only that, but a mention of all the major competitors with an honest factual comparison with them is really handy as well. In the FLOSS world, naming competitors won't necessarily cause a major problem and does a huge amount for trust.
But yep also, this nginx page is a testimonial page. Testimonial pages bring very little value as it's 100% subjective, and usually just "fanboy" content. And the 2nd half of your post is equivalent.
Personally I find Apache easier to configure, and with mpm-event its as fast as nginx (albeit both are fine httpds, and nginx has cleaner code). I could also compare both to text editors.
But none of this brings valuable info to me. It's way too subjective, and you know how people get touchy feely -and extremely subjective- when it's about favorite brand/software/company/validation-that-what-they-use-is-the-current-cool-thing
True and while creating such a list please consider to add as well a short list of scenarios in which you would not recommend the use of the product even if this may be a little "contra-marketing" and is probably even harder to come up with for the authors than the positive list.
Nothing quite inspires confidence like that.
Let me expand your comment (with your permission) to make it more general.
"Every project, open source or not, needs to be run with all the branches of a proper organization"
Let me flesh it out with an example: some time ago there was a flame here and on proggit about cricitisism of C++. Some arguments and counter-arguments (http://www.reddit.com/r/programming/comments/197dn1/introduc...) got me thinking (have mercy, o' HN C++ overlords)
1. Problems are due to power and flexibility Design : build simple and tight systems or get smart enough to build tight complex systems.
2. clang is fixing template error messages Execution: reasonable to demand this be done before standardization
3. This is an implementation problem Management apathy: Passing the buck
4. C++ is not one language but actually many different ones Marketing : Positioning
etc
There should be no reason why open-source projects should be 'good code, bad with everything else'.
The number of projects I've encountered which don't even have this .... Words fail me.
Maybe it's because I'm not a developer or working at a startup, but I get majorly annoyed whenever I click on some "Show HN" link only to be presented with a landing page on some unheard of web site that contains a few nice images and a text box wanting me to give up my e-mail address before I can even see what the application looks like or, in many cases, before I even know what the hell it is or is supposed to do!
(On a side note, that may be the longest sentence I've ever written.)
> SIGN UP NOW!
For what!?
Why not just have your load balancers (which can operate cheaply at the TCP layer) throw traffic directly at your application servers?
If you need caching, that's cheap to do, too. If you need static file serving, can't you another load balancer end-point that points directly at static content servers, or make your application servers faster?
Is nginx primarily useful for slow application server runtimes that can't keep up with what nginx can do?
Also, there are many that use nginx as the load balancer (including me). Would a TCP load balancer be better? Possibly but it also comes at an additional cost whereas nginx is free and far more flexible with routing HTTP content.
I'm not even going to summarize all the other things nginx can do via modules (Lua, memcached, etc -- http://wiki.nginx.org/Modules).
The main reason is that nginx is much better and faster at handling certain things than Python:
* handling HTTPS and serving plain old HTTP to the application server so Python doesn't have to worry about it
* doing the gzipping of content before it goes out
* routing requests to different places/ports based on various elements matched in the URL or HTTP headers
* virtual hosts, i.e., "Host" header matching and routing things to the right place based on that
* various request sanitization, like setting client_max_body_size, ignore_invalid_headers, timeouts, etc.
Historically we've also had multiple types of application servers, some Python and some C++, and nginx routes requests to the right app server (based mainly on URL prefix).
We also use nginx to do GeoIP with the GeoIP nginx module (though arguably that would be just as simple in Python).
Edit: Note that we don't use it because our "application server is slow" (it's not). Also, I know some people use nginx to serve static content, because it's usually much faster/better than say Python at doing that -- we serve static content via Amazon S3 and a CDN, so that's a non-issue for us.
In most cases reverse proxies are useful as application firewalls, where you control what passes and what doesn't in an application-independent way (i.e. your systems administrators can do this without the need to touch applications - which in many enterprise settings can't be easily touched by developers, much less by operations).
This is why I have yet to use nginx, and stay with good-old apache. Apache is extremely configurable (not only is mod_rewrite very powerful, but you can insert your own request mangling scripts for that weird edge case).
Apache is also good enough for most cases. For applications with a few thousand users hanging on the site all day, apache can handle it just fine in a 5-year old, low-end Celeron rack server, with just 5% CPU usage even with all connections being SSL for both Internet and application server traffic.
Caching and load-balancing are nice things to have, but not the reason for having a reverse proxy in most cases.
I guess a TCP load balancer could do them based on IP as well, but IPs don't identify sessions as well as cookies can.
If you have non-idempotent GETs in your app, then that's the app's fault. If Nginx is retrying POSTs then it's Nginx's fault.
Actually, many times "your app" is somebody else's app that you bought or an app that somebody else develops and you don't have any control over it. Sometimes those apps are just bad (well, most enterprise apps are) and your only hope is that the infrastructure that you do happen to control doesn't make it worse.
I've never used nginx, so I don't know if the parent has a point or not. However, having a reverse proxy retrying _any_ requests to backends by default seems very bad form to me. Do you want your routers resending packets? It's the same thing.
I recall reading about a very popular image website doing exactly that and, when Google attempted to index it, some strange things happened to the images as the web crawler chased down all those "safe" links.
No: HTTP GET is explicitly idempotent and cachable. As an HTTP client, you are supposed to be able to send the same GET all day, and it's up to the server to not screw that up.
Bad behavior from apps you don't control is a fact of life. Ignoring it doesn't make it go away, and behaving like it doesn't exist can make it worse.
But once you introduce other software in the ecosystem that is guaranteed to send you these sorts of things, you'll damn well better release a new version of your package that works with them.
The "feature" is 'proxy_next_upstream'. We spent time cursing this Nginx definition of a feature.
http://serverfault.com/questions/51320/setting-up-nginx-to-n...
I come from the php world, and people always say how much lower-memory nginx+php-fpm is than apache+mod_php. Well no doubt! If you understand how the architecture actually works, it's clear this isn't a fair comparison. mod_php means php is fully-loaded for serving statics, not to mention having a smaller pool of php-fpm processes will take less memory and also be faster (due to less context-switching) than the larger number of mod_php processes.
However the real comparison should be between nginx+php-fpm and apache+mpm_event+php-fpm. Nginx is an evented server, so at least try to compare apples-to-apples. I've seen very few comparisons of nginx with mpm_event.
Also, apache's default tunings are much more geared towards modest server usage whereas nginx's seem more geared towards high scalability. An argument could be made that apache should have "better" defaults, but since at scale you need to start tweaking your OS/rlimit/etc to prevent bad things from happening you can see why apache might stick with more modest tunings ootb.
Our app has a lot of apache custom config and so I was a hesitant to try to switch to nginx due to the risk of getting things wrong porting the configs. We did move from apache/mod_php to apache+mpm_worker and php-fpm and we've been able to improve throughput (especially on statics) at a far lower memory footprint. Key to success in lowering the memory footprint was dropping ThreadStackSize (from 8M default to 1M). What a difference!
Other than that, the competition is good for everyone. I am sure nginx pushed apache to work on mpm_event much harder.
As for ThreadStackSize: it impacts virtual memory but not actual memory usage. Actual memory usage stays the same. You should never use the 'vm size' as a good measurement of memory usage. Unfortunately memory management on modern OSes is complicated and people don't understand the numbers, so they arbitrarily pick a column in 'ps' and conclude that X is bloating memory... :(
I definitely know VIRT is complicated. I couldn't find any kind of clarity on it. If you know of a good guide I'd love to see it.
That said, virtual memory still likely affects some kernel decision-making. For instance the oom-killer was kicking in on a daily basis until I made these changes. With mpm_worker using 250+ threads, I was able to reduce the "committed" by several gigs. The system overall seems more stable and the oom-killer hasn't reared its head in days.
I can imagine that the stack is treated differently since it'd be a terrible idea to page out stack. I couldn't find proof, but if I were a kernel I wouldn't page out stack :)
One of the main selling points for me. Especially for personal projects, I can go with a more affordable vps plan by using nginx instead of apache.
Better yet: What exact is Passanger? (Explain it like I'm five)
Their site says, "Phusion Passenger is an application server for Ruby (Rack) and Python (WSGI) apps." - so it's something that runs below Nginx and run Ruby code?
Or is it an extension for Nginx/Apache?
Thanks!
The benefits are not lost. Phusion Passenger integrates into Nginx to give you the benefits of both. For example one of the tasks of Nginx is to buffer HTTP requests and responses in order to protect apps from slow HTTP connections. Phusion Passenger fully makes use of this Nginx feature and even extends it.
No. but you will see the benefits only at a high req/min, because with Apache it would have to spawn new threads to deal with so many requests, taking up memory and other resources, while nginx just sends the requests directly to the passenger instances as needed. basically nginx would use less memory.
> What exact is Passanger? passenger is a module that understands and handles rails requests. So when a request comes in to nginx for an image, css or other static asset, nginx will find it and send it back, when the request is for a rails controller/action, then it will send it to a passenger instance to process and then return the results to you
hope that helps
I mean, I understand why Apache needs to do it: with Apache, you have things like mod_php running in-process, so it makes sense to restrict Apache, running one of Bob's scripts, from accessing Alice's files.
But with Nginx, anything with "intelligence" runs out-of-process. What Nginx expects you to do is to run it as one user, but run each app server (in PHP terms, each FCGI socket daemon) as the user whose files that server should access. (Or, better yet, run the app server in an LXC container along with a bind mount to only the files it needs to access. Very Plan9y.)
It's true many of benchmarks out there use flawed methodologies, so lets try to fix that. When you benchmark something as complex as Apache, people are going to find faults with your initial run, no matter how careful you are. This is why you need to be completely transparent with you setup configuration and should be prepared for a followup run with user suggested settings.
If you're familiar with Apache configuration then you should have no problem with Nginx because the way both servers structure their config files is very similar. I prefer Nginx config files however because it feels more like writing JSON whereas Apache config files are like writing XML, especially in the area of virtual hosts. That said, neither is better, its really more about what you're comfortable with and prefer. Nginx had most of the same configuration options and the tough part was figuring out what Nginx calls the corresponding Apache option.
For me there was a barely noticeable performance difference with Nginx being faster. The caveat here is that in my case I started moving all of my static sites and sites with "simple" php script type apps over to Nginx and used the apache server for a very few apps that were running more memory and CPU intensive apps. The Nginx server was also new and clean while the apache server had been in use for a great many more things including non-web applications and managing private got repos for about 20 code bases.
Nginx did use about 25% less memory in my case than apache even while serving up more sites.
I love being able to host multiple SSL sites on a single IP with no hoops to jump through with Nginx. On Apache your options are to acquire more IPs or set up SNI which for me was more hassle than it was worth.
So since we're on HN I'm assuming most people are serving Ruby or Python based apps with Nginx or using it as a reverse proxy. That's cool and all but there's still an enormous cross section of the developer community using it to serve php and as I have a lot of sites that were originally built in php my Nginx server needed Php-fastcgi. I mentioned earlier that configuring Nginx was a breeze since most of my apache knowledge transferred over but setting up fastcgi was not a breeze. It's easy to get set up and working but actually understanding what it's doing and if you really do want to configure it in the way whatever online guide shows you is the tough part. On apache you'd just install mod_php5, 'a2enmod' it, and then all you need to worry about is your php.ini file. On Nginx you have the added step of adding a config block to each server block for php. That's easy enough to get the gist of but then you start wondering if you've made the right decision after you read those warnings about improperly setting it up leading to security holes with file uploads and then you start wondering what other options should I know about, should I implement them, etc. Maybe I'm totally misguided here but with mod_php you didn't worry about security. You only worried about the security of your actual code, the server itself (firewalls, ssh, port blocking and all that), and your .ini's. So that was a downside for me but not insurmountable by any means.
It's also far easier to find information on apache than Nginx. Nginx has a ton of available support and articles and tutorials out there but most of them cover the same narrow section of topics and are contradictory sometimes. The Nginx wiki itself even has warnings about getting advice from outside the wiki in the Pitfalls section. Of course you need to be careful when sourcing information from the web no matter what the topic but I felt more secure in searching for Apache information than Nginx information.
I really love Nginx though. It can really take quite a beating without even batting an eyelash as I've seen. That said, I'll still be using Apache as my "workhorse" server for some time until I can get more Nginx experience under my belt. So I'd say take these testimonials for what they are: just testimonials. True or not, any piece of software worth using can get people to rave about it. What's important is if they're situations, expectations, and needs align with your own.
How is this best of both worlds?! You add one more layer where things can go wrong, for mostly no benefit nowadays. Now people need to know how to properly configure and secure two pieces of technology that do the same things. I know this is the most popular setup nowadays for new php deployments and this is why I hate it so much! Why does everyone have to complect anything from software to devops nowadays?! If you start with something like this and use the same mindset of "just the best tool for the job, nothing else, not matter how many tools you use" for everything from devops to frameworks to your app you'll end up sooner or later with something that makes asp.net and iis setups or even spring based enterprisey ones look like a breath of fresh air! Better spend some extra effort to make your php app work great on the nginx+php setup. My advice for anybody doing PHP: remember why you are using PHP and not something else in the first place! because you want everything to be drop-dead no-think simple, from devops to framework, to app! because this way you can concentrate 90% of your effort on front-end, design and pr (and it's not necessarily bad if this is how your business should work)!
How it is best of both worlds? Nginx simply does not have all the features Apache have. Take a look at the .htaccess rules that Wordpress and WP-Supercache needs. It's much easier to to run Wordpress on Apache and put that behind Nginx than to figure out how to rewrite the rules to Nginx form (or worse, update the rules when they change). There's also a ton of Apache modules that have no Nginx equivalent, or no easy Nginx equivalent.
Why I use PHP? Because some apps don't have good Ruby or Python equivalents. After all these years I still haven't found anything better than Wordpress and phpMyAdmin. If it's my own code, sure, I'll write Ruby, but I'm talking about apps.
Putting Nginx before Apache allows it to protect Apache from slow clients because Nginx buffers requests and responses.
What? Neither Apache nor nginx can serve multiple SSL sites off a single IP without a UCC certificate, SNI, or multiple IPs. SSL requests have their Host header encrypted, which means the server doesn't know which SSL certificate to present until after encryption.
Thanks for the link!
</joke>
Long live to Nginx !
nginx's ssi capability is so bare currently. however, it is an excellent reverse proxy for me.