Hacker News Reader

Comment by dtech | Hacker News Reader

Couldn't these results be skewed because Nginx is often used as a reverse proxy?

If there is Apache or something custom behind Nginx it will show up as Nginx I guess. I do not see this issue adressed and it might cause significant skew if you look at the top websites (since they will more often deploy these kinds of tricks)

View on HN

Isn't it considered best practice to serve your static files through Nginx itself and only reverse proxy requests for dynamic endpoints? And if that's the case, Shouldn't Nginx be counted as a full web server?

You can configure Nginx to cache and serve html or as a load balancer. In these cases it isn't the "real" web server, and it's common.

I disagree. I don't care if nginx is in front of apache, varnish, or some ruby or python web server. If nginx is what serves the final request to the client, it's the webserver. Period.

edit: nginx is the last mile. You can't say everyone in the USA has access to fiber because further upstream their traffic traverses a fiber network. Their last mile is DSL/Cable/etc. When it comes to the user experience, last mile is all that counts.

Sure. But it doesn't make sense to not count the other web servers involved. (Even though that's often not possible)

By that logic (I'm not saying the conclusion is wrong), no one has fiber because we always end up translating it to electrical pulses before hitting the cpu, and chrome is the largest webserver because it always checks its own cache before going out to the network.

If you start calling things like varnish a web server you'll confuse a lot of people. You generally call them according to what role they serve in your stack, and for Varnish and at times Nginx, that is a reverse caching proxy.

Depends, but from an application and development perspective, which I'm sure most are assuming here, no. If you can remove nginx and still serve your site/application, then nginx is not your web server. If nginx is acting as a reverse proxy or a cache, then that is all it is.

By that logic, the webserver would be the last thing in front of the user, their router, their ISP, whatever...

I dont agree. Their router processes data below the application layer. Thus why not define the webserver as the last server to serve at the http layer ?

Good point, or perhaps more used as the LB? We prefer Varnish as the reverse proxy, but we are using nginx as load balancer, which still shows up as the server in the response header, even though we exclusively run apache on the back-ends to serve the PHP application. I am not sure how typical this setup is though.

Unfortunately too typical. You're keeping all the performance issues with a LA<database>P stack (high resource-use variance going from low to high traffic), and merely adding layers in front. Unless you need an apachehttpd-specific feature, you should look into moving to a nginx + php-fpm setup.

You're being awfully presumptuous -- there's nothing to indicate the parent isn't already using an apache2+php-fpm setup. Not all apache2+php users are using mod_php (which is where performance woes come from).

Yeah, we are using apache2+php-fpm. The application behind is Drupal, which is supported on apache2 only (mostly) unfortunately.

I guess from a higher perspective this is a support resource vs savings from technical performance question, but my feeling is that right now the lack of support knowledge and experience is more painful than the performance.

We use nginx as a load balancer on its own machine and distribute requests to a small farm of machines running windows/iis.

Nginx is great as a load balancer, not quite as sophisticated as HAProxy but the SSL support is good and it gets the job done pretty well.

I'm sure we're not the only ones.

Nginx is used as a reverse proxy for less strong application servers. IMHO (and experience) doing it for Apache would be pretty useless.

Depends. I remember having an issue with an apache/mod_php app that was using way too much memory.

The app was doing polling every 10 seconds and apache had a 15 seconds keep alive. So each user of the app was maintaining an apache process alive.

Disabling the keep-alive was not acceptable, so I just threw nginx in front to do the keep-alive, memory usage was immediately reduced by ~75%.

If I knew apache better I might have been able to do it with just apache, but nginx is so simple to use...

wouldn't just changing the apache keep alive have been even easier than setting up a whole other web server and adding that to the mix?

If the nginx keep alive was set at 15 seconds, you'd have had a similar problem, no?

No. Because Nginx doesn't dedicate a thread or process to each open connection.

Doesn't that raise security concerns?

Yes, it requires a sandbox for things like PHP.

But it's limited to it. Most other web stacks come with their own sandbox. And Apache also puts PHP in a sandbox for unrelated issues.

Depends heavily on how you have configured Apache. If you are using something like PHP and the forking model (most common MPM configuration), you can only handle as many requests as you have workers; additionally you are spinning up a full PHP interpreter when serving static assets. In my experience[1], putting Nginx in front of Apache to serve static assets and leaving Apache as a sort of application server is one of the lowest hanging fruit in scaling a LAMP application.

[1] Was Co-Founder/CTO of a medium-sized PHP PaaS company

This was how we did it at my last job, a state university.

I'd agree, but I suspect that anybody who cares about PHP-performance has probably already moved to FPM.

> additionally you are spinning up a full PHP interpreter when serving static assets.

I think that if you do this you are one RewriteRule away from doing it right.

> In my experience[1], putting Nginx in front of Apache to serve static assets and leaving Apache as a sort of application server

I also think that using nginx only for static content is wasting perfectly good resources for nothing. Apache can serve static assets just as good as nginx does. No need for an other layer in your stack.

At absolute bare minimum it allows for error mitigation for the underlying server application.

In other words, your site doesn't necessarily have to be down even if Apache is down (assuming you're for some reason bound to Apache).

Exactly. I have much more Apache servers than Nginx, but you can't see most of those Apache instances from the outside.

You reverse because you can't have two apps on the same port, obviously...but the real reason is because apache's lack of features...and apache is bad!

Even if apache is running in the background to serve up things like php, its most likely because there is some config that hasn't been converted to run the site on something like fast-cgi or FPM.

I wonder how something like haproxy appears when nginx is behind it.

Reply on news.ycombinator.com