Live data from Hacker News

Why Use Nginx?

wiki.nginx.org

51–60 of 91 posts

Re: Why Use Nginx?

#51

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…

I recently bought some leathergoods from a company who have a page called "Our Competitors". It's a list of 20 companies who make the same categories of goods.

Nothing quite inspires confidence like that.

Re: Why Use Nginx?

#52
post #50

Earlier quoted context omitted.

You don't need fast go to serve php through nginx. You can - and probably should - just use nginx as a reverse proxy in front of php-enabled apache. Best of both world.

Nginx+PHP-FPM blows the doors off of Apache+mod_php. Why "should" you do this?

There is a particular use case where output buffering worked better on Apache/mod_php, but I believe it's been fixed.

Re: Why Use Nginx?

#54

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…

I recently bought some leathergoods from a company who have a page called "Our Competitors". It's a list of 20 companies who make the same categories of goods. Nothing quite inspires confidence like that.

Interesting. I'm sure they gained some customers due to that confidence, but I wonder how many they lost.

Re: Why Use Nginx?

#55

One thing I still don't understand is why one would use a proxy server at all? 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 fast…

An HTTP level load balancer like nginx can do session affinity, which is helpful when your application server isn't stateless.

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.

Re: Why Use Nginx?

#56

Earlier quoted context omitted.

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

My mistake. I was always told Nginx can serve multiple SSL sites with no extra work required besides the usual configuration you'd change for a single SSL site.

So you said you "love being able" to do something that you have not tried (since you didn't know it was impossible you must not have tried it)? I think you should evaluate systems based on how they work for your use case, not by how they might work if you wanted to do something later.

Re: Why Use Nginx?

#57

Earlier quoted context omitted.

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

My mistake. I was always told Nginx can serve multiple SSL sites with no extra work required besides the usual configuration you'd change for a single SSL site.

It can; it's just using SNI without explicitly asking you to enable anything.

Re: Why Use Nginx?

#58
post #48
post #40

Earlier quoted context omitted.

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

I'm not saying that it's a standards violation or anything like that. I'm not even arguing against GET retries, but only against them being default. 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.

I would argue that relying on the behavior allowed by a standard is the only way to make it actually be allowed. Otherwise, people code to your unwritten, stricter standard, relying on nobody else ever sending them something that is allowed. Then, when something allowed by the standard does happen, they blow up.

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.

Re: Why Use Nginx?

#59

Earlier quoted context omitted.

I recently bought some leathergoods from a company who have a page called "Our Competitors". It's a list of 20 companies who make the same categories of goods. Nothing quite inspires confidence like that.

Interesting. I'm sure they gained some customers due to that confidence, but I wonder how many they lost.

If you are making those comparisons, you should also wonder about the quality of those customers. I.e. people who stay with you still are probably profitable customers.

Re: Why Use Nginx?

#60

One thing I still don't understand is why one would use a proxy server at all? 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 fast…

I think one response that's missing here is that application servers might use a lot of RAM while they're running, so you can only afford to have a few instances running. In such cases, it's better to have nginx buffer the response and deal with the slow clients, than holding up an application server for the duration of the transfer.
Post reply on HN