Live data from Hacker News

Why Use Nginx?

wiki.nginx.org

31–40 of 91 posts

Re: Why Use Nginx?

#31

Every single project, open source or not, needs to have a "Why Use It" page. (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 se…

> Every single project, open source or not, needs to have a "Why Use It" page.

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.

Re: Why Use Nginx?

#32
post #12

I dropped Apache in favor of Nginx about two years ago. Haven't looked back since then. It's so much easier to configure and it uses far less memory.

I am using lighty for that reasons. Can anyone compare lighttpd with nginx performance on small servers like Pis?

Re: Why Use Nginx?

#33
post #22
post #11

Earlier quoted context omitted.

Oh really, does it do it for POSTs? It should retry for GET, but not POSTs (which is exactly why there is a difference). 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.

That's a pretty broad statement to make... You are assuming that out there only "your app" exists. 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 n…

If you have an app that completely ignores the HTTP specification like that then you could well have bigger problems.

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.

Re: Why Use Nginx?

#34
post #11
post #8

A big gotcha with nginx is if you have an app server behind it and you foolishly have a long running web request which runs longer than the proxy timeout, nginx will retry the original web request. Better make sure everything is idempotent and don't have long running web processes. It is bad design, but we ran into this. Code that used to run in a few seconds started taking longer and then ran infinitely long without…

Oh really, does it do it for POSTs? It should retry for GET, but not POSTs (which is exactly why there is a difference). 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.

It definitely did it for POST. That is what surprised us. We had a lot of users added and as I said the few second operation started taking much longer and we discovered it was because their spreadsheet uploaded was getting uploaded again and again because it kept timing out. Was not fun.

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...

Re: Why Use Nginx?

#35

I'm a newbie - if I install Passanger to be able to run Rails apps on on Nginx, are these benefits lost? 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!

Phusion Passenger extends Nginx and turns it into an application server. An application server is a program that runs application code, so in this case it allows Nginx to run run Ruby/Python code. Likewise, the Apache version of Phusion Passenger turns Apache into an app server that can run Ruby/Python code.

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.

Re: Why Use Nginx?

#36

I'm a newbie - if I install Passanger to be able to run Rails apps on on Nginx, are these benefits lost? 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!

> if I install Passanger to be able to run Rails apps on on Nginx, are these benefits lost?

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

Re: Why Use Nginx?

#37
post #12

I dropped Apache in favor of Nginx about two years ago. Haven't looked back since then. It's so much easier to configure and it uses far less memory.

I am using lighty for that reasons. Can anyone compare lighttpd with nginx performance on small servers like Pis?

I dropped Lighttpd years ago because on some occasions it used 100% CPU for no reason. It didn't make the server crash, and Lighttpd itself appeared to run fine otherwise, but still... the CPU usage was there for no reason. This was never solved, and development also seemed stalled. So I switched away from Lighttpd to Nginx. Nginx just kept working and working, never broke once.

Re: Why Use Nginx?

#38

Nginx is great, but before you get down and start using it, make certain that you'll never, ever use any features it doesn't support. I was bitten by this when I found out Nginx has no equivalent to Apache's mpm_itk_module.

Absolutely correct. Use Nginx because it's small and fast. But don't use it because it's fully featured, because compared to Apache it's not. But that doesn't have to be a problem. I use Nginx by default, and on the occasions that I need an Apache feature I just reverse proxy the virtual host from Nginx to Apache.

Re: Why Use Nginx?

#39
post #22
post #11

Earlier quoted context omitted.

Oh really, does it do it for POSTs? It should retry for GET, but not POSTs (which is exactly why there is a difference). 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.

That's a pretty broad statement to make... You are assuming that out there only "your app" exists. 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 n…

I agree with that. Automatically resenting requests is not good. Better to simply timeout. And if there are enough timeouts that it's causing a problem, the functionality should be restructured.

Re: Why Use Nginx?

#40
post #22
post #11

Earlier quoted context omitted.

Oh really, does it do it for POSTs? It should retry for GET, but not POSTs (which is exactly why there is a difference). 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.

That's a pretty broad statement to make... You are assuming that out there only "your app" exists. 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 n…

> 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.

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.

Post reply on HN