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?
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.
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.
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.
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.
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.
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).
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!
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.
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.
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)
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.
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).
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.
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/
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.
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.
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)