[p49k]

This is kind of a weird statistic to try to analyze. So many uses of nginx are just the act of putting an Apache/IIS/etc site behind nginx, so technically, both servers still have market share but you only see nginx. It's just that nginx makes it so easy to do certain things, like supporting modern HTTPS, that you might as well add it to your stack rather than replace something.

[ag_47]

As someone younger who never really used Apache, I don't see any reason to do anything with it instead of Nginx. Other than supporting "legacy" setups, whats the point of Nginx load balancing Apache? Configuring nginx is just so much more intuitive.

[mfontani]

At $main_work, the reason is that there's a bunch of RewriteRules which last I checked simply couldn't be done by NGINX.

OTOH, Apache suffered from the "slow loris" attack, so the whole shebang ended up being nginx sitting in front of a few front-end apache instance kinds, which sit in front of a dozen or so backend apache instance kinds.

I find it interesting that although on those servers there are 12x more Apaches than NGINX, it might get counted as a server "using nginx"...

... and that's just because the whole she-bang sits under cloudflare, which reports Server: nginx-cloudflare ;)

[aluminussoma]

Apache can mitigate slowloris attacks through mod_requesttimeout. I recommend using this.

[zzzcpan]

Both nginx and apache are vulnerable to slowloris. To mitigate an attack like that you need an architecture with a scheduler, that kills slow connections, not a naive event loop.

[pram]

Probably a lot of mod_* uses like PHP applications that haven't been migrated to php-fpm or something, and JBoss/Tomcat/Websphere/Weblogic websites. You of course can just proxy all of these things with nginx, but it's probably not worth it for most companies.

[developer2]

PHP is definitely a huge chunk of the reason why nginx has taken over Apache. php-fpm with nginx is the defacto standard, and PHP is far more prevalent than a lot of people think. Apache's mod_php(X) vs. nginx+php-fpm isn't even a debate. If someone is currently using Apache+mod_php, they probably have a smaller product that will eventually have to switch to nginx+fpm in order to scale.

While I imagine PHP is the single largest reason, other languages that support or expect the use of fastcgi are also very easy to configure with nginx, whereas I can count on one hand the number of businesses I've seen using Apache's mod_fcgid.

[Zachery]

I'm probably about 2 years out of being bleeding edge, but php-fpm&nginx are far from defacto standard. At least when you look at how the web is being served at large, looking at cPanel/WHM.

I don't believe cPanel/WHM even supports nginx yet as a standard option.

[developer2]

Not to be disrespectful - I know that cPanel and similar have their place - but no real business that expects to have a presence is using cPanel or any other "easy setup".

[wolco]

fpm is being dropped now that php 7 contains many of the improvements that made fpm popular. php_mod+apache with .htaccess turned off is the faster stack. Put a nginx server to server static content in front and that's the fastest stack going forward

[devwastaken]

FPM isn't just popular because of speed. Its popular because of pools and the fact that its not a giant security risk by having it installed. mod_php shares permissions across everything it executes. If you have any site on the same Apache stack as another, they're accessible to each other as far as PHP is concerned. This makes the attack surface of a website significantly larger unless you're hosting exactly one site you have locked down to one directory.

I also really doubt that php7.1 mod and apache without .htaccess is faster than nginx and php7.1-fpm under 'ondemand' mode. Even a 5$ DO server can handle hundreds of requests a second to big frameworks like Drupal or Mediawiki, and they're securely seperated. Locking down permissions on a group level to the executing php-pool, so you can then make only specific users belong to that pool and bind a directory in their home to the actual website location.

[adrianfalleiro]

FPM is being dropped? This is news to me, where can I read about this?

[wolco]

As people upgrade many are choosing PHP 7 through mod_php

The below are links to benchmarks and discussions around mod_php vs. fpm. These are from last year 2016. Fast forward to today; I am seeing people move to php 7 and move back to mod_php. I believe we are at the start of a movement. Articles/stories will follow but only after the fact.

https://www.symfony.fi/entry/symfony-benchmarks-php-fpm-vs-p...

https://www.reddit.com/r/PHP/comments/4bi9a4/why_is_mod_php_...

[scurvy]

I can only speak for myself, but I'd rather avoid the Apache HTTPD stack altogether. If you run multiple PHP FPM pools, it's nicer and easier to only recycle individual pools as necessary (rather than the whole process). Important to those of us who run lots of microservices (or even lots of PHP sites) on single hosts.

[smsm42]

nginx is much more simple than full-service servers like Apache. Which is good if you want to do something easy fast (like terminate TLS, proxy, load-balance, simple redirect, simple header munging, etc.). And not good if you want to do something more complex and get into learning how nginx rewrite rules really work (totally not obvious), how if and other predicates really work (multiple articles in docs suggest it's not obvious at all) and what limitations are needed to achieve the simplicity and quickness. So if you want your webserver to do something complex, you'd go for Apache. But may still put nginx in front for LB, static content, pre-cache TLS, etc.

[user5994461]

A good reason to use nginx (or better HAProxy), is to stop people from writing endless mess of redirect and rewrite rules.

[smsm42]

Not many people do it just for fun. Stopping people from doing what they need to achieve job being done is usually not the most productive idea.

[adrianratnapala]

What people need to do to get their job done is very, very, frequently to work around an existing mess with new hacks that make the mess even harder to clean up. And if that's what they need to do, then they should do it.

But we should also ask ourselves how to get into such messes less often. That is, how to systematically reduce the number of early-stage design errors. One trick is to choose tools that forbid known anti-patterns.

That means the designers must work harder up-front to figure out a system that can do without the work-arounds. But that is a feature, not a bug; indeed that is what our processes should try to achieve.

[user5994461]

There are very few justified usages that require to write maze of rewrite rules.

Most people do it because they have no idea what they are doing and they never decided on a naming convention for their apps and domains.

[Something1234]

What are some justified uses of rewrite rules?

[ag_47]

Fair point, but,

> if you want your webserver to do something complex, you'd go for Apache

I would tend to disagree. Assuming "complex" = "business logic", Apache hardly seems the right choice. PHP/Python/Node/GoLang or Lua right inside nginx would be more appropriate in most cases, imo.

[smsm42]

There are degrees of complexity, there's a kind of spectrum even. If you want a full-blown business logic that requires language like PHP or Go, it's insane to try and make Apache do it. If you need a set of simple rules that are within what Apache (including there all the module ecosystem) can and is designed to do, it would be a big mistake, costing a lot of scalability, to deploy high-level language instead. Right tool for the job, always.

[ag_47]

> if you want your webserver to do something complex, you'd go for Apache

> a set of simple rules that are within what Apache (including there all the module ecosystem) can and is designed to do

[smsm42]

Again, there are degrees of complexity. Very simple - nginx, kinda more complex - Apache, somewhat complex but still doable without using Turning-complete language - third-party Apache modules, needs Turing-complete language or you're wasting your time - Python/PHP/Perl/pick your poison.

[detaro]

Shared hosting setups where you want .htaccess support (or something comparable, but same basic issue: requires some additional layer to validate and generate a centralized nginx configuration, or some other extra layer, with Apache it is built in and well-documented).

WebDAV support.

[ag_47]

As far as htaccess support, from the couple Shared hosting providers I've used, lighttpd has been the server of choice.

[gcb0]

A: Features.

[jamiesonbecker]

HA Proxy would be a better choice if the only goal is reverse proxying to another web sever; nginx excels at static files, uwsgi, stuff like that. Even the commercial/paid nginx Plus only comes close to what's already built into ha-proxy, which is totally open source.

[chaoticsamuel]

Agreed, I mean is a reverse proxy even a server? The number of people who use Nginx for load balancing is huge, so when they say people are switching to nginx from Node.JS, I'm just like: "Dude, I only use Nginx for my kubernetes ingress, with plenty of services behind using Node.JS rather than any monolithic everything server" So is my server Nginx, Kubernetes or Node.JS, or Python, or Java? :-/

I think this statistic is conceptually a little behind the times in some ways

[benaadams]

Nginx will overwrites your origin server headers https://trac.nginx.org/nginx/ticket/538 so for these stats it would get picked up as nginx even though its only forwarding

[benaadams]

And nginx overwrites origin server headers; whereas most other gateways/reverse proxies don't https://trac.nginx.org/nginx/ticket/538

[need2sleep]

Indeed.

This is hardly a legitimate statistics, how many sites sit behind CloudFlare/Sucuri/Incapsula IP's, which are always nginx reverse proxies.

I don't think anything changed that much as of late, apart from more and more people adopting CloudFlare.

[Sir_Cmpwn]

People do that? And it's widespread? I've never heard of this.

[jamroom]

https://www.nginx.com/resources/admin-guide/reverse-proxy/

[Sir_Cmpwn]

I know you can reverse proxy, but I haven't heard of anyone reverse proxying to apache.

[vidarh]

There's a massive amount of Apache modules and installs of stuff that has various dependencies on Apache where it's simply not worthwhile to expend any effort to convert it to Nginx, but where it's worthwhile placing in Nginx in front if you prefer Nginx for things like caching, load balancing etc.

[fgonzag]

That was the original way (at least the most common way) to do CGI. Nginx as a reverse proxy / load balancer / SSL terminator / static file server pointing to a backend running apache for mod_cgi or mod_fastcgi. And a lot of people would have both web servers running on the same server. You already have a web server, why do you need two?! Just pick one!

[vidarh]

I feel old now. It was nowhere near the original way - CGI predates Nginx by a decade.

> why do you need two?! Just pick one!

When they're good at different things.

[ue_]

Reverse proxying to Apache is still how I run my Perl CGI scripts. I'm not sure of a better way to do it that supports running multiple scripts.

[pwenzel]

Webfaction has been doing it that way since roughly 2008, initially introduced as a way to speed up serving of static files.

https://blog.webfaction.com/2008/12/a-little-holiday-present...

[nkozyra]

It's extraordinarily common but largely unnecessary.

[lucideer]

I'd say the most common use-case (particularly given the ubiquity of PHP on the web) is to support mod_php for people not wanting to move to php-fpm for whatever reason - often some weird legacy reason, or sometimes just familiarity and change overhead.

[justbaker]

I've done it and yeah don't do it.

[ZephyrP]

This must be the single most common use of nginx, I'm totally blown away that someone as prolific as you has never heard of it.

[eloisant]

No, the most common use of nginx is to put it in front of rails/play/jee/whatever framework that doesn't ship with a full featured web server.

[tyingq]

It's also probably undercounting Nginx, because Cloudflare uses Nginx, but returns the headers for whatever it's proxied to.