I happened to read Netcraft's May 2014 Web server market share report the other day. We can all equivocate and gnash our teeth over Netcraft's data collection methodologies, but there has to be something to Netcraft's claims that Apache is losing market share to other Web servers. I think that part's true, but it's not the whole picture.
Let's take a look at what we have for commonly used Web servers today. Apache and Nginx are the big names on the Linux side, with a smattering of other options such as Lighttpd and Cherokee. On Windows, you can run Apache and a few others, but the overwhelming favorite is, of course, IIS. Although we certainly could run PHP and Apache on Windows, we most likely won't. Meanwhile, if we're developing an ASP.Net site, we're going to use Windows and IIS. For the most part, we can count on a hard divide between IIS and all Linux-centric servers.
[ Also on InfoWorld: Nginx passes Apache as Web server of choice among top sites. | Web performance issues got you down? Download InfoWorld's Building Web Performance Deep Dive PDF. | Cut to the key news for technology development and IT management with the InfoWorld Daily newsletter, our summary of the top tech happenings. ]
This isn't really a matter of Linux versus Windows, but a matter of open source Web servers versus IIS. Open source Web servers are clearly winning by a large margin, even if they appear to be cannibalizing their brethren rather than taking more and more market share away from IIS. This isn't simply because one solution is better than another. It's more a matter of using the right tool for the job -- indeed, using all of the tools at your disposal.
Let's dispense with IIS for now and concentrate on what's happening in the Linux and open source Web-serving world. Specifically, let's dig into Apache and Nginx, both highly popular these days. There are certain tasks and workloads that favor one or the other, and there are many workloads that favor both, working in tandem to deliver a single site.
Apache could be considered the cruise ship of the Web-serving world. As a nearly 20-year veteran, it's older than the others, with the most mature code base of any other option. Given its longevity, it enjoys compatibility with just about everything, and its modular design allows for custom development of modules that can be plugged in to serve all kinds of purposes, both known and as yet unknown. Apache has a massive library of documentation and years upon years of configuration examples and guides on the Internet. It has something for everyone, and it can be counted on to work. It also can take some serious tuning to bring it up to the performance level that many sites need. Cruise ships don't turn on dimes.
Nginx, on the other hand, was developed to be as fast as possible. Its lithe, thin design and minimalistic configuration are clearly aimed in that direction. Nginx also has been constructed to provide other services than just Web serving. It's a very capable reverse proxy and can even function as a load balancer -- though there are generally better options for load balancing. Nginx, as it seems, does turn on a dime. Also, plenty of folks think the Nginx configuration syntax makes more sense than Apache's, but your mileage may vary (greatly).
However, Nginx doesn't directly serve dynamic content as Apache does. With Apache, installing the PHP module gets you PHP support, and it's usually there right out of the box. Other languages share similar support mechanisms, resulting in a big-tent approach to Web serving.
With Nginx, you need to use another method to drive dynamic content, such as PHP-FPM, which is a FastCGI process manager for PHP. Within the Nginx configuration, you then define a regex match for all PHP files and pass them through a local listening port or (preferably) a local socket that runs the code and delivers the results. You can also easily pass those tasks to Apache processes running on the same server. These methods work well, especially with Nginx caching, but they come with overhead.
Thus, many sites will use both: Nginx as a reverse-proxy front end that kicks back to Apache to do the dynamic processing. Further, since Nginx excels at delivering static content, some sites will offload those tasks to dedicated Nginx servers that do nothing but shovel static content such as images, CSS, and JavaScript files, or streaming media files. If you're inspecting those sites from the client level, it may in fact look like Nginx is running the show, when it's just fronting Apache or other services.
The fact is there's plenty of room for all the Web servers currently available. The choice of server will be dictated by the dev team first (unfortunately, in some cases) and by the implementation last. There are site-construction decisions to be made based on ratios of dynamic to static content, geolocation of resources, local caching, load balancing, CDN utilization, and so forth. We shouldn't be thinking in terms of Apache versus Nginx or even versus IIS. This isn't the Vi-versus-Emacs fight. We can all get along quite nicely.
This story, "Apache or Nginx? Go with both," was originally published at InfoWorld.com. Read more of Paul Venezia's The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.