My Take: IIS vs. Apache

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. 

 

Summary

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

Share this post: email it! | bookmark it! | digg it! | reddit! | kick it! | live it!

9 Comments

  • Interesting read, even for people like me who do not have much knowledge and in-depth-views about the topic.

    I just discovered your blog through a back link and want to use the opportunity to ask a set of questions:

    What do you answer customers who ask you after the vendor lock-in? In case of IIS you have to use Windows as the underlying system, and you cannot switch it. In case of Apache, you can use whatever you want. If there are such customers, what do you tell them?
    (Starting from that it is unlikely that you release a Linux version of IIS anytime soon).

    The other question is in a similar direction:
    Microsoft's history is not the most popular one regarding MS's attempts to spread into a new field of software technology: when it entered a new field, it usually killed all other competitors through at least debatable methods. Also sometimes by providing superior technology, but often enough by the usual methods only a monopolist can use.
    What do you answer people who are afraid about that topic? What is MS's stand on Firefox in this regard? How can we be *sure* that the IIS will not implement techniques which can only be used by the IE or Windows programs in general?
    Sure, I know the MS-Firefox talsk of the last months, but these might as well have been just flashs and nothing else.

    If you wonder where these questions come from or why I am so critical with MS: I pointed that out at my blog. From my point of view the major people at MS are still Bill Gates and Steve Ballmer, not the people who invited the Firefox developers or the people who tried to implement common standards in IE7.

    I would appreciate if you could take some time to at least write down what you think about such or similar concerns.

  • Hi liquidat - thanks for stopping by. I enjoyed your original blog post and the resulting discussion so much it motivated me to post this entry. I welcome input from all sides of the debate.

    Just wanted to get one thing out of the way before rumors spread: you're right - there is no version of IIS for Linux planned anytime soon. :) I smile only because we have a huge investment in the underlying OS and our goal is to make IIS the best possible Web server out there for Windows customers.

    Of course, that does mean that we require Windows, so if you want to use IIS, you'll have to buy a copy of Windows. It turns out that for many people, this isn't a problem. They've already decided for one reason or another to choose Windows, and so choosing IIS is a pretty natural option. For them, we want IIS to be not just a default choice, but something they really enjoy and get a lot out of.

    For others who are trying to decide on a platform to build on, you're right that they can choose IIS on Windows, or Apache and any other supported OS. That may sound like an easy choice to you, but it turns out that it is pretty complicated for most customers. "Vendor lock-in" as you phrase it is one thing to consider, but it is a question of priority for most people. In considering it, one has to ask: how often do I really plan to change OS platforms? Is it really important to my business that I am able to move from one server OS to another on a frequent basis?

    For some people the answer may be "yes". For most customers that I talk to, the more pragmatic questions are ones like: where am I going to invest my time and money? what is my organization already familiar with and capable of using? What are the features and capabilities of the rest of the software stack, from developer tools and frameworks to administration and management tools... from databases and identity to performance and scalability... from security track record and support options to total cost of ownership and much, much more. Answers to these questions tend to be more important than who / where you're getting your software from.

    I say all of this without trying to downplay the ultimate transparency and cross-platform freedom that open source software like Apache provides, and there are certainly more than a few who prioritize these requirements very high. For many customers who choose Windows, the power of having an integrated stack for developing, deploying, managing Web applications, and the convenience of having one vendor to secure, support and assist them is a top priority. And thank heavens for them, they pay my bills. ;)

  • Hi Bills, thanks for the detailed answer :)

  • Hi Bill,

    I work for a hoster I read with interest the App Pool per site as being the default config for new websites.

    How does this compare with IIS6 in terms of performance, resource utilisation and management practicalities?

    Doing this on IIS 6 is a management and tuning nightmare particularly when we host roughly 800-1000 sites per server.

    Cheers
    Kev

  • Kev -
    I have great news for you.  We've focused a lot on the shared hosting scenario, and we have a dedicated test bench to simulate it here and we've been pushing the scalability.  Of course, the numbers you get will depend on a lot of factors, but we are pushing well beyond the limits you describe. 
    If you want to read more about how we recommend hosters do shared hosting on IIS7, we've just published a whitepaper here: http://www.iis.net/articles/view.aspx/Deploy-an-IIS7-Server/Deployment-for-Web-Hosters/Shared-Hosting-on-IIS7?tabid=1.  I have a dedicated team of technical experts ready and willing to help you get started like other hosters have with the IIS7 GoLive (http://iis.net/goLive).  If you're interested, send me an email and I'll get you in touch with them. (click the email link at the top of the page).
    thanks-
    bill

  • Yepp... fact is close to 80% of the world's servers run Apache... and one of the many good reasons they do is because we can use mod_rewrite and have "normal" search-friendly URLS while taking advantage of the server-side functionality of PHP.

  • Hi Kenty-

    Not to pick knits, but your "fact" is off by a few bits. :)

    The netcraft survey cited tracks the marketshare of Web servers by counting Web sites, and clearly shows Apache at 56%, not 80%. http://news.netcraft.com/archives/2007/05/01/may_2007_web_server_survey.html And if you consider that many Web hosters run multiple "sites" on a single server, and that most hosters probably run Linux, you quickly realize that the number of actual Apache "servers" (not sites!) on the internet is even less than 56%.

    In any case, I do agree that friendly URLs through the use of mod_rewrite is a very good thing, and you can expect to see similar functionality built on top of IIS7 in the near future. In addition, as I mentioned, IIS now has fast and reliable support for PHP (in fact, you may be quite surprised if you do a side-by-side performance test), so customers can enjoy PHP on Windows and IIS every bit as much as they do on Linux/Apache.

  • Bill - thanks for posting this. It made a very interesting and informative read! As someone who's primarily a windows developer/user who only uses Linux based web hosting (my personal site for example) because it's generally cheaper when comparing two feature-sets, all the work that's been done in IIS7 has given me hope.

    I strongly believe that (licensing costs aside) a big part of the reason for the price differential between Linux and Windows hosting has been the fact that IIS has traditionally been harder to manage in a hosting environment than Linux. Distributed configuration and a much more modular architecture are definately a big step towards removing this difference, so thankyou!

    One final thing - I may've missed it in my searches, but it seems remarkably hard to configure IIS7 to host classic ASP with the same behaviours that you get by default in downlevel versions, any chance you could blog about this? With flexibility comes additional complexity I guess!

  • Hi Rob - just posted on the subject here: http://blogs.iis.net/bills/archive/2007/05/21/tips-for-classic-asp-developers-on-iis7.aspx

Comments have been disabled for this content.