Nginx has replaced Apache as the most used web server among the top 10,000 sites | Hacker News Reader

Nginx has replaced Apache as the most used web server among the top 10,000 sites

w3techs.com

274 pointsMarionG75 comments

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)

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.

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.

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.

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

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

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

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

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

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.

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.

There are different statistics with different methods and outcomes. For example the netcraft server survey over 975,262,468 sites shows a market share of Apache: 37.58%, IIS 33.41%, nginx 14.60%. Source: http://news.netcraft.com/archives/category/web-server-survey...

I know this is off-topic but I'm also surprised by Google Server's popularity. Can 10% of the top 1000 web-sites really be serviced by Google? You've got to pay for the reports, but I wonder if people using Google's CDN for static assets could be skewing those results. Does anyone have insight into the methodology used to collect this data?

They are probably counting each regional Google server as a separate "site" because it has a different hostname (different tld). There are easily 100 of those, esp. if YouTube counts as well.

Wouldn't most of those be Google own websites ?

If we consider a separate www.google.x for each country then we would get to around 100 very quickly, I guess.

The remainder would be filled by youtube, gmail, etc...

Any opinions on Nginx being more difficult to setup/run than Apache? I'm considering switching, but I really have enough overhead to deal with!

I'm very biased on this subject but I find the configuration file to be far more simple. The lack of .htaccess support is also a blessing in disguise as everything is in explicitly defined locations.

Just give it a go. Remember you can set it up to run on another port, e.g. 81, 8080 etc. so you can get it working whilst still having Apache up and running on your site.

For popular CMS applications you can normally find some helpful .conf file to get you started.

You will also need to setup php-fpm if you are running a PHP flavoured 'LAMP' stack.

I find nginx way easier to set up than Apache, at least for "standard" (PHP, Ruby/Rails, static) applications and sites. The config file syntax is cleaner than Apache's, and setup is easy (through your favourite package manager). The memory footprint of nginx is also smaller than that of Apache (at least with default settings).

Cool! I never thought of that!

Will it be noticeably faster than my current (tuned) Apache setup?

Nginx is faster, however, it is possible to get Apache to be quick and it is possible to make nginx slow (I think 'if' statements are to be avoided in the config).

However, as well as speed there is also the amount of load that can be sustained. Nginx wins on this front as well as with speed.

As mentioned, run it on another port and see for yourself. When you are happy with it turn off apache on the chkconfig, set nginx to the other port, stop apache and run nginx -s reload to swap over the port. Yep, you can get the whole thing installed, tested and deployed without reboot or downtime!

If you have anything to do with Drupal (and possibly Wordpress) as well, you might run into issues.

At least concerning Drupal, a lot of plugins require changes to the .htaccess file(s), and at least when I tried, this was hard to translate to nginx.

But there are some .htaccess to nginx converters, so I'm not sure if that is a big issue at this time.

And as others have said, you might find the nginx approach to be much more comfortable than .htaccess. I did.

Drupal works flawlessly with Nginx[1], and there is little magic involved. You even have good handling of private files, permission and such.

There's only a few modules that require changes to the default ".htaccess" (basically just overriding Apache default logic) of Drupal, like the module Boost. But since Nginx can serve as both a application server and reverse proxy, you can have the best of both worlds, without doing hack-y things like Boost, which basically generates a lot of static files.

You don't want to use those converters, as they usually rely heavily on ifs, which is a bad thing, when things normally can be handled pretty well with the "try_files"-directive.

[1] I've been using it in my stack for a couple of dozen Drupal sites for about two years now.

Thanks for the information! I've mostly moved away from Drupal, but I still maintain a number of sites for some clients. Good to know a move to nginx is an option.

Way easier to configure than apache!

"We didn't get the answer we wanted."

"Then reduce the sample size!"

We abandoned Apache as we found configuring Tomcat with Apache to be a major pain whereas configuring NGINX with Tomcat or other J2EE application servers is almost a no-brainer. Ditto with SSL termination. Since then we've moved all static file serving to NGINX as having both Apache and NGINX did not make sense. I know that a lot of other JVM shops did the same.

How do you do this? Are just using a proxy?

I use mod_jk with Apache. With mod_jk you use the AJP protocol to communicate with Tomcat. It's one line in your Apache config and a few lines in /etc/libapache2-mod-jk/workers.properties (Debian)

Are there any support for AJP for Nginx today?

Stuck on Mod_jk and AJP ? I feel your pain ; and I fled from it a long long time ago.

You don't need AJP with NGINX; this enables you to easily work with any J2EE app server or web server . I ran into issues with configuring glassfish with Apache and thus began using NGINX. Why bother with AJP ?

Yes setting up NGIX as a reverse proxy for Tomcat/ Glasshfish whatever is very simple. Setp a NGINX on your desktop and you will never have to connect to port 8080 ever again. Also it can serve static content while lettting your app server handle application urls.

can someone link up a good "nginx for newbies" type resource for someone who is familiar with programming?

I hope it's kosher that I link my own blog since it deals specifically with nginx: http://blog.martinfjordvald.com/2010/07/nginx-primer/

This is one of the best primers you get for getting started with Nginx, and mfjordvald is a genuinely nice and helpful guy!

Here's a good starting point for getting your config right:

https://github.com/h5bp/server-configs-nginx

http://nginx.org/en/docs/beginners_guide.html

After reading the beginner's guide (which is pretty good and cover most of the simple stuff), I suggest reading http://wiki.nginx.org/Pitfalls and http://wiki.nginx.org/IfIsEvil to see some "best practices" (which usually aren't followed in many tutorials out there, even on nginx's own wiki).

i note postfix usurped sendmail much faster.

sendmail was genuinely terrible: monolithic, unused, uninstallable attack vectors everywhere (echoes of openssl), near-binary configuration which required learning a complex macro language. Even Sendmail X bears more resemblance to Postfix than it does to Sendmail 9.

Replying to myself: s/uninstallable/unremovable/. Though everyone seems to have got what I meant.

funnily enough nginx also is a IMAP/POP3 proxy server

It is also a SMTP proxy, so you can put nginx in front of your postfix servers.

Curious how Node isn’t even mentioned. Interesting how many years until it catches up.

Probably never. As any site in the top rankings is likely going to be using nginx as a reverse proxy to node.js.

How can I tell, by visiting a site, what web server is being used?

curl -I www.ycombinator.com

This gives you the HTTP Header, example output: HTTP/1.1 301 Moved Permanently Server: nginx Date: Mon, 26 May 2014 16:11:30 GMT Content-Type: text/html Content-Length: 178 Connection: keep-alive Location: http://ycombinator.com/

Oh wow, that's cool. I didn't know that. Thanks.

For a laugh do it on http://www.reddit.com/

I get this:

    $ curl -I www.reddit.com
    HTTP/1.1 200 OK
    Content-Type: text/html; charset=UTF-8
    x-frame-options: SAMEORIGIN
    x-content-type-options: nosniff
    x-xss-protection: 1; mode=block
    Server: '; DROP TABLE servertypes; --
    Date: Mon, 26 May 2014 18:37:12 GMT
    Connection: keep-alive
    Vary: accept-encoding

Mostly just by looking at "server" header. For example, Hacker News has server header as cloudflare-nginx

Did anyone else pause when they read the title line...

"Usage of web servers broken down by ranking".

I'm picturing a graph of the most commonly broken web servers for half a second.

I'll take the downvotes as a "no we didn't, and we think you are trying to be funny".

But, I actually did read that for a half a second and think the phrase "broken down" can be done without. It doesn't add anything in my opinion, I know it is broken down (its a graph), the phrase is unnecessary, and it caused me at least to stumble mentally for half an instant.

Hypothetically, a company like Hyperspin could create a chart of webservers that were offline (most likely to break) in the past X days. I think the results would be interesting. Example: Out of 1,234 servers that were offline for > 1 hour in the last month, 40% Microsoft, 30% Apache, 20% NginX, etc.

I assume the too-shy-to-reply downvoter thinks downtime is not a direct correlation to a problem with the webserver. While that's true, I was hoping to argue that the stack chosen is indicative of deeper problems such as stack complexity. A too-complex stack is more prone to break, which is part of the appeal of NginX, its simplicity. You could also prove Microsoft stacks are more or less likely to fail. For example .01% of Microsoft servers were offline last month, .009% of Apache servers were offline (> 1 hour) last month, etc. PS: If it wasn't obvious, I made up hypothetical percentages.

some people are a bit too free with downvotes.

I can only imagine what these people are like in real life. I suppose aggression is necessary part of the human condition and that saddens me. But... hey, if it makes one feel powerful to down vote, go ahead. Personally I find it cowardly unless the person can take a second to explain why but whatever.... (Exceptions made for blatant cases of trolling and drop dead stupid comments of which yours was not one... and I appreciate the support. Thanks. PS. fellow UF alum! Looks like I graduated the year you started.).

Go Gators ;-) As long as we're off on a tangent, this made me realize downvotes here are (pretty much) anonymous, but comments are not. I think it would be interesting if anonymous notes could be attached to downvotes. It would also be interesting if those anonymous notes were either public or private. So hypothetically, if you had 10 downvotes, you could hover that and read why people downvoted. Another approach (I like this idea better) the downvote could trigger a menu of tags like [Nonsense] [Rude] [Grammar] etc. Anonymous or not, constructive criticism is a good thing, in my opinion.

That's a good idea. Anonymous notes on a downvote. Hope to keep seeing you post on here. Gainesville seems like a million years ago and it was a great time.

I'm confused by this title and the article here.

The graph in the linked shows that "Apache is used by 60.5% of all the websites." while nginx is at 20.7%...

How could these numbers possibly mean that nginx has replaced Apache as the most used web server? When is 60.5% more than 20.7%? IS it opposite day?

You need to look at the legend. For the top 10,000 websites, Apache is used by 39.1%, and nginx is used by 39.2%.

I see now; I didn't notice the distinction in the subject header here.

Reply on news.ycombinator.com