Web Server comparison : Apache versus IIS
28/10/2010 1 Comment
I ran across Apache at 56% – what is wrong? by /home/liquidat this weekend, and the resulting Digg thread, and enjoyed reading the age-old IIS vs. Apache debate waged by loyalists on both sides. It is great to see the passion for Web servers still very much alive. This is one of the reasons I love software…it is so much more than bits and bytes. Software, good and bad, evokes an emotional response from users. It frustrates the crap out of me when it doesn’t work like I want it to, and it makes me nod my head and say “cool…” when it does something really powerful that I don’t expect.
The IIS vs. Apache debate has been going on for a while, and reminds me of the Mac vs. Windows debate, which also never gets old. I used to be a die hard Windows fan. I got my hands on a Windows 95 beta and was so blown away by it. I was one of those crazy kids that went to CompUSA at midnight the day it was released and bought my own copy. Later in college I dual-booted into Linux so I could have access to gcc and all the great development tools we were using in class. Now I run Mac OSX and Vista at home.
When I got out of college, I worked for a start-up ISP, and ended up focusing a lot of my energy on the Web hosting side of the business. We started out with a Sun Ultra server, running Solaris, then deployed a bunch of Linux servers. We used Zeus and Apache as a Web server. They were both great. I admire Apache for a lot of reasons. It is a solid Web server with a great extensibility model, and is very reliable when run on Linux.
My history with IIS
I got my hands on IIS when it first came out in 1996. At first it seemed like a toy (maybe because it was) but it quickly grew up. With ASP in IIS 3.0 I fell in love. After hacking so many CGI applications together in C or PERL, I was blown away at how productive I could be with ASP, especially when MDAC came out and made data access so easy. If I had to make a bet, I’d guess this is one of the reasons people love IIS to this day: it is easy to setup, use, and incredibly powerful to program against.
I pushed the IIS4/NT 4 option pack very hard at the company I worked for in 1997, and we deployed the last beta in production. It required a reboot every day in order to run properly, and depending on which series of patches we installed, it sometimes required more, but it was worth it. I remember once installing an Oracle patch one morning, on recommendation from an Orcale support engineer, that took out the entire server and required a full rebuild. That was the day I learned to never install patches on a production server without first testing them. :)
IIS5 came out with Windows 2000, right as I joined Microsoft, and ended up being a disasterous release for the IIS team. I remember sitting through meeting after meeting with customers who were hit by Code Red and Nimda, who were justifiably furiated by the impact the vulnerabilities had made on their business. IIS wasn’t very popular inside the company at the time either, as these were the first broad-scale internet worm attacks against any Microsoft product, and it took time for others to realize: it can happen to you.
The IIS team learned some very hard lessons about security vs. features in 2001 and 2002. We poured over our code, we hired independent contractors to come pour over our code, fuzz it, hack it, and try to break it. The result is quite possibly the most secure and reliable Web server ever with IIS6 – released with Windows 2003 Server. Don’t take my word, search http://secunia.com for IIS security issues yourself, and compare it to any other Web server product.
And with 2007 came IIS7 in Windows Vista, and later this year, with Windows Server “Longhorn”. IIS7 is more like a “v1” release, than a “v7”. I can honestly say it is the biggest release of IIS ever. It has more fundamental improvements and new capabilities than any previous release of IIS, and hasn’t lost sight of the basics: security, reliability, performance. I think it will change the Web server market. If you’re already an IIS customer, there is a lot to look forward to with IIS7. And if you haven’t checked out IIS for a while, or you are still worried about security or reliability, it is time to give IIS a second look.
Bad reasons to avoid IIS
If you’re saying to yourself: IIS isn’t as secure as Apache, or isn’t as reliable, or isn’t as fast, you should think twice.
Security. If you’re worried about IIS security vs. Apache, you’re concerns are outdated. Check out http://secunia.com and compare IIS5 and IIS6’s track record for the last 4-5 years and compare it to Apache. Having been on the IIS team during Code Red and Nimda I can tell you it was a very painful experience and one I don’t ever hope to re-live, nor do I wish it on my worst enemy. The IIS team learned hard lessons in 2001, and the results speak for themselves. Is IIS perfect? Nope, it is still build by faliable humans and we make mistakes just like every other engineering team.
Reliability and Performance. IIS6 included a new process model which can reliably host Web applications, and monitors them for health and responsiveness. It can proactively recycle applications when they are unhealthy. IIS7 takes this process model to the next level by automatically isolating each new site when it is created in its own Application Pool, and dynamically assigning a unique SID (identity) to the AppPool so it is isolated from all other sites on the box from a runtime identity perspective – without any additional management required. It also isolates the configuration for the AppPool, so it is impossible to read configuration from other sites on the server. This provides the ultimate Web server architecture for Windows – a high performance multi-threaded server that provides secure isolation of Web sites by default and is also agile enough to respond to poor health conditions and gracefully recycle applications
If you’re worried about IIS performance and reliability when running PHP vs. running on Apache, you’re concerns are definitely valid. Up until recently there were only two ways to run PHP: the slow way (CGI), and the unreliable way (ISAPI). :) This is primarily a result of the lack of thread-safety in some PHP extensions – they were originally written for the pre-fork Linux/Apache environment which is not multi-threaded. Running them on IIS with the PHP ISAPI causes them to crash, and take out the IIS process serving your application.
Fortunately, the Microsoft / Zend partnership has brought about fixes to these issues with many performance and compatibility fixes by Zend, and a FastCGI feature for IIS which enables fast, reliable PHP hosting. FastCGI is available now in Tech Preview form, and has also been included in Windows Server “Longhorn” Beta 3. It will be included in Vista SP1 and Longhorn Server at RTM.
Reasons you should check out IIS7 if you use Apache today
There are so many new capabilities in IIS7, it would turn this already long post, into a short novel to list them all. If you want lots of specifics, go read through the IIS7 site. Here are a few reasons you Apache users might be interested in looking at IIS7:
Text file configuration
Apache has httpd.conf – a simple text file for configuration – which makes it very easy to edit Apache configuration using text/code editors or write PERL or other scripts to automate configuration changes. Since the configuration file is just a text file, it also makes it easy to copy configuration from one server to another. Unfortunately, Apache does require the Administrator to manually signal Apache to reload configuration in order for changes to take effect.
Many IIS customers dread IIS’ configuration store – the ‘metabase’ – and for good reason. It has been an opaque configuration store like the registry since it was introduced in IIS4, and while there are many tools and APIs to use to configure IIS with, nothing beats being able to open up your configuration in the text editor of your choice and directly change configuration settings. With IIS7, all IIS configuration is now stored in a simple XML file called applicationHost.config, which is placed by default in the \windows\system32\inetsrv\config directory. Changing configuration is as simple as opening the file, adding or changing a configuration setting, and saving the file. Want to share configuration across a set of servers? Simply copy the applicationHost.config file onto a file share and redirect IIS configuration to look there for its settings. And whether your configuration is stored locally on the hard drive, or on a file server, changes take effect immediately, without requiring any restarts. All IIS configuration settings are self-described in a schema file that can be accessed by going to \windows\sytem32\inetsrv\config\schema. Adding new configuration to IIS is as simple as dropping a new schema file in this directory, registering it, and it automatically becomes available through IIS’ cmd-line tool and programmatic APIs.
Distributed Configuration (by default)
Apache supports distributed configuration with a feature called .htaccess. It is a powerful feature that enables configuration for a Web site to be overriden using a simple text file in the content directory. Unfortunately, due to the way it is designed in Apache, using it incurrs a huge performance hit. In fact, the apache.org site recommends you avoid using it whenever possible.
IIS7 supports distributed configuration in web.config files, and has some important advantages over .htaccess. Web.config is the file that ASP.NET uses today to store configuration, so developers now have a single file, format and API to use to target Web site / app configuration. Imagine storing your PHP, Apache and Web Application settings in one file. This distributed configuration support is very powerful, and allows for every per-URL configuration IIS property to be set in distributed configuration. IIS7 caches web.config data, which avoids the per-request performance hit Apache suffers from. The IIS implmenetation for distributed config is so good we’ve made it the default for a bunch of IIS configuration that we know developers typically want to set along with their Web sites. For example, if you use any IIS7 tool to override the default document for a site or application, that setting will be stored in the web.config file for that directory by default. Of course, you can override the default and store everything in IIS’ global configuration file if you want, and you can decide on a section-by-section basis which settings you want distributed, and which you want to keep centralized. There is much more granulatiry in IIS’ configuration locking support over Apache, enabling you to even lock at the attribute level if desired.
Extensibility (C/C++/C#/VB.NET/and 30+ other languages…)
As I noted above, Apache has had a very modular architecture with powerful extensibility for many years. Apache’s architecture has allowed many people to take it and add / modify / extend the Web server to do many custom things. The resulting community modules for Apache has been impressive to watch. IIS’ ISAPI extensibility hasn’t been a complete slouch: some of the world’s biggest application frameworks have successfuly run on ISAPI, including ASP, ASP.NET, ColdFusion, ActiveState PERL, etc. Unfortunately, the number of successful ISAPI developers does seem to be smaller than the successful Apache mod developers, and the product team itself elected to rarely use ISAPI to build actual IIS features.
This all changes with IIS7. With IIS7, IIS introduces a new native extensibility interface, CHttpModule, on top of which we ported all of the IIS features as a discrete, pluggable binary. The IIS core Web server itself is a very thin event pipeline, and each of the IIS features can now be added and removed independently. The extensibility point, CHttpModule, is much more powerful than ISAPI, and provides a fully asynchronous super-set support for extensions and filters. Don’t like how IIS does XYZ feature, rip it out and replace it with your own: you have all the APIs the IIS team has.
Even more impressive, IIS7 introduces managed extensibility of the core Web server via the existing System.Web IHttpModule and IHttpHandler interfaces, enabling any .NET framework developer to extend IIS at the core and build a new, custom or replacement feature. I showed this off in a recent blog post on how to build a SQL Logging module that can add to or replace the built-in W3C logging using .NET in less than 50 lines of code.
Advanced Diagnostics and Troubleshooting support
Whether you’re running IIS or Apache, troubleshooting problems can be a real bear. Applications running in a high-performance, multi-threaded, console environment are very tough to debug, especially when in production use. IIS7 innovates in several key ways to make the support for these situations far better than what you see with any other Web server.
First, IIS supports a feature called ‘failed request tracing’, which is really very cool. Simply give IIS a set of error conditions to watch out for, based on response code or timeout value, and IIS will trap this condition and log a detailed trace log of everything that happened during the request lifetime that led up to the error. Seeing requests timeout on a periodic basis, but not sure why? Simply tell IIS to look out for requests that take longer than n seconds to complete, and IIS will show you ever step in the request lifetime, and including duration to complete each step. And you’ll see the last event to have fired before the timeout to occur. Are you seeing the dreaded “Server 500 Error – Internal Server Error”? Tell IIS to trap this error and then browse through each step along the request to see where things went south. I know of nothing like this with Apache.
IIS also supports real-time request monitoring and runtime data. Want to know which requests are in flight on the server, how long they have been running, which modules they are in, etc? IIS can tell you from the cmd-line, administration tool, or even programmatically via .NET and WMI APIs. It is very easy to now look inside IIS and see what’s going on inside your Server.
Rich Administration APIs and Tools
This is an area where IIS has traditionally shined, and IIS7 takes the lead even further. IIS7’s new administration tool is very simple and easy to use, but extremely powerful. It is now feature-focused: simply click on a Web server, site or application and see every feature available to manage. On the right hand pane there is a set of simple administration tasks for each scope that makes it easy to create new sites and applications, modify logging settings, or see advanced settings. The administration tool remotes over HTTP, making it possible to manage the server locally or over the internet. And the tool fully supports the distributed configuration model, making it possible to add ‘delegated’ administrators for Web sites and applications and allowing them to use Web.config or the same Administration tool to configure their Web site. The administration tool is also completely modular, and built on top of a new extensibility framework, making it easy to add new features into the tool.
In addition to a rich administration tool, IIS also ships AppCmd.exe, a swiss-army knife for cmd-line administration. With it, you can set any IIS setting, view real-time request and runtime information, and much more.
IIS7 also includes several programmatic interfaces which can be used to manage the server. Sure, you can use PERL to hack away at the new text-based config file if you want, or you can use rich, object-oriented APIs in any .NET or script language if you prefer. Microsoft.Web.Administration is a powerful new .NET api for programmatically managing the Server. IIS7 also includes a new WMI provider for scripting management using VBscript or JScript.
IIS7 is a major overhaul of the Web server. It builds on the rock-solid security and reliability of IIS6, and promises some very powerful new extensibility and management capabilities that meet and exceed what Apache can do today. It’s already in Vista, so you can use it on the desktop today, and with Beta 3 it is available for free for production use through the GoLive program.
I’m quite certain this won’t end the debate of which is the better Web server, but I thought I’d add my two cents. ;)