By Jeffrey Carl, Matt Loschert and Eric Trager
Web Hosting Magazine represented the high water mark of the market for print publications around the Internet Service Provider industry. In other words, it was probably my last-ever opportunity to get a paid gig writing for something that would appear physically on a newsstand. It was intended to be more focused than Boardwatch and, according to Wikipedia, “was written and edited with a deliberately ‘edgy’ style, designed to appeal to the primarily young and male constituency of the ISP industry.” Matt Loschert, Eric Trager and I contributed a few long-form articles before the magazine – like the rest of the telecom industry at the end of the dot-com era – vanished without much of a trace.
Welcome to part one of the Open Source vs. Commercial Server Software Shootout. This time around, we’ll be looking at Web Server Software (Microsoft IIS vs. Apache); Site Scripting (Microsoft ASP vs. PHP); and Microsoft Web Compatibility (FrontPage extensions and ASP options). Before you send nasty response e-mails (these, especially nasty threats, should be addressed to [email protected]), keep in mind that this is merely the advice of three long-time server admins; your mileage may vary). Tax, tags, title and freight not included.
Web Server Software
Overview:
The breakdown between commercial and open-source web server engines is more about the operating system than the software itself. The most popular commercial option is Microsoft’s IIS, or Internet Information Server. It runs only on commercial operating systems: Windows NT, or the more robust Windows 2000. The far-and-away leader in open-source server options is Apache, and, while it features a version that runs in the Windows server environment, its flagship server runs under even obscure flavors of Unix and has no real competition.
The battle of IIS vs. Apache in raw performance evaluations is as tangled as the Linux vs. NT benchmarks are. Depending on whose tests or opinion you listen to, you could hear everything from “Apache is blown away at heavy web loads” to “IIS all-around blows goats.” However – all OS and configuration issues aside – it’s probably safe to say that IIS performs better with heavy loads of static pages and Apache tends to handle lots of dynamic DB/CGI stuff better (at low loads, there’s little performance difference to speak of). Keep in mind, though, that because IIS is so tied to Windows and the Apache/Win32 version lags behind its Unix counterparts, it’s unlikely that there will ever be a really even contest between the two.
Since IIS is the clear leader with Windows servers and Apache is by far the most popular choice for Unix foundations, the comparisons here are largely about the duets of OS and webserver. Such a comparison is appropriate, considering how critical the operating system is in funneling the horsepower to a server with hundreds if not thousands of simultaneous clients (we hope your state motor vehicles department is listening).
Commercial Option: Microsoft Internet Information Server 5.0
Platforms: Windows NT/2000
Publisher: Microsoft, www.microsoft.com/windows2000/library/howitworks/iis/iis5techoverview.asp
IIS is a free package when Windows 2000 server software is acquired, and was available as part of an option pack for Windows NT server. IIS is technically free, but if your goal is to run a webserver and you choose IIS, you’re paying for it by choosing NT or Windows 2000. NT still starts at around $500 for the base server package, while Windows 2000 goes for around the same price and that’s only starting at a five-client license. While that license permits as many web hits as possible, those hits can only be unauthenticated requests; simultaneous accesses that are under a username/password are limited to the number of users permitted by the license (which really cramps your style if you’re running adult-oriented membership houses).
There are advantages to using IIS. One is a relatively simple installation and set-up process. Using an all-too-familiar GUI, a few points and clicks will have IIS serving pages on your Windows system in no time. Once running, IIS is administered with the same familiar Windows GUI and allows for easy access to run-time information including current access statistics and resource consumption. IIS also includes some niceties Apache doesn’t offer, such as making it easy to throttle bandwidth for individual hosts. The IIS setup allows file security to be set easily through the GUI (Apache allows some of this, but not as many options as IIS, and relies on Unix file security options for the rest). Also, it has a clear advantage in dealing with sites created using Microsoft tools (see Microsoft Web Compatibility below).
Using IIS also has its drawbacks. When looking at the open-source model as another option, the potential for security issues with IIS has to make you sleep less easily. Open-source bugs are usually squashed pretty quickly, when there are thousands of developers who examine the insides of a program. Microsoft has had issues in the past dealing with revealed exploits in an (un-)timely fashion, and there’s no reason to believe that IIS is any more immune than Internet Explorer or Windows itself.
Second, because it is tied to Microsoft’s server OSes, you’re … well, you’re tied to Microsoft’s server OSes. We don’t have the several thousand pages it would take to get into this, so we’ll leave it as a matter of preference. If it’s “the right tool for the job” for you, so be it.
ALTERNATIVES: There are plenty of other commercial web server software options. The leader in marketshare after IIS as measured by Netcraft (www.netcraft.co.uk/survey/), is iPlanet Enterprise Edition 4.1 (www.iplanet.com/products/infrastructure/web_servers)– the former Netscape server, now a Netscape/Sun collaboration – which starts at $1495; the iPlanet FastTrack edition is available for free. Zeus (www.zeus.com) is widely known as a heavily optimized, very speedy server for Unix platforms, and starts at $1699.
WebLogic (www.bea.com/products/weblogic/server) is a popular application server that costs some amount of money, which I wasn’t able to figure out by reading their website. WebSite Professional (website.oreilly.com), the “original Win32 webserver,” starts at $799. And, for those brave enough to run a webserver on MacOS 8/9, there’s WebStar (www.webstar.com/products/webstar.html), which starts at $599.
Open-Source Option: Apache 1.3.12
Platforms: AIX, BSD/OS, DEC Unix, FreeBSD, HP/UX, Irix, Linux, MacOS X, NetBSD, Novell NetWare, OpenBSD, OS/2, QNX, Solaris, SCO, Windows 9x/NT/2000 (plus many others; see www.apache.org/dist/binaries for a list of supported platforms with pre-compiled binaries)
Publisher: The Apache Software Foundation, www.apache.org/httpd.html
The Netcraft (www.netcraft.co.uk/survey/) survey listed the Apache webserver running 61 percent of sites reporting. While Apache’s awesome domination has slipped a little in recent years, it still holds the majority and runs well ahead of IIS, which has (as of this writing) a (relatively) paltry 19.63 percent of the market. Why is it that Apache has such a Goliath-like grasp on the field of webservers in use?
The reasons are numerous and simple. First, Apache is free. Consider that the business of the Internet is still relatively very young and, therefore, not terribly consolidated… yet. There are quite a few small hosting providers that need powerful web servers, and Apache presents an obvious choice, running on equally inexpensive operating systems like Linux and FreeBSD. Consider also that many businesses host sites remotely with those same providers, and Apache presents what has traditionally been the easiest server to configure and maintain remotely (through Telnet/SSH).
Second, Apache is stable and powerful. In years of work on both lightly and heavily worked Apache servers on different operating systems, I’ve had to work very hard to create a scenario that choked the server. The only problem that consistently knocked down Apache was the human one: like any program, Apache can’t work around typos in the configuration file and sometimes isn’t too descriptive about what’s wrong even through its apachectl configtest mechanism (although you’d be amazed at what you can get away with). Also, while IIS allows easy setup of most security permissions through its GUI, it can’t compete with the easy flexibility of Apache’s htaccess feature (especially when doing things like limiting access to a host with password permissions).
The Apache system is modular in nature as well. The initial package has what is necessary to get a web server online, but to accommodate special functions like FrontPage compatibility, persistent CGI, on-the-fly server status or WebDAV, server modules can be downloaded and installed to be incorporated into the Apache daemon. Apache maintains a directory of resources on available modules at www.apache.org/related_projects.html#modulereg. The benefit is a streamlined program by default for what the majority of users need, and the ability to fatten it up for special functions only when necessary.
Apache has a few disadvantages. It isn’t nearly as easy to install as IIS; but for anyone familiar with administrative aspects of Unix systems (and that base is growing faster with Linux’s ballooning popularity), it’s rather simple to obtain, install, and configure. Support for Apache is free, but is not as easy to obtain as picking up the phone and calling Microsoft. Of course, considering the user base and its roots in a largely helpful Unix culture, plenty of assistance is there if you’re willing to look (and, please, look first). Lastly, Apache’s performance in some situations isn’t all it could be – hopefully the impending arrival of the heavily-rewritten Apache 2.0 will fix much of that.
ALTERNATIVES: Popular (relatively speaking) alternatives include AOL’s in-house (but open-source) AOLserver (www.aolserver.com); and the tiny but very fast thttpd (www.acme.com/software/thttpd).
Final Judgement:
Even the O.J. Simpson jury wouldn’t have much problem with this one. Apache takes the lead in so many categories that it’s not much of a contest. The user statistics don’t lie, either: in terms of servers out there, Apache beats IIS by three to one. While on the surface this could be attributed its cost (zero), remember that IIS is also free if you already have Windows NT/2000 (you did pay for that, right?). Ignoring that factor, Apache is generally regarded to be superior to IIS in reliability and overall performance, which, with a price tag of zero and a support network of users across the globe, makes it an extraordinary value.
IIS has some bright points, which is important if you’re in the position of being locked into running your webserver on a Microsoft platform. If Microsoft is your exclusive IT vendor, if you’re hosting sites created with Microsoft tools or using third-party apps only available for Windows, or you have lots of Win NT/2K experience and little or no desire to learn Apache and Unix, IIS is your clear choice. Otherwise, even if you have Microsoft platforms running your IT infrastructure, administrative functions, etc, it may be well worth it to purchase additional systems to run Unix, just so your web functions can be handled by Apache.
Microsoft FrontPage Compatibility
For a web hoster, it’s becoming increasingly imperative to be able to provide compatibility for the primary issues associated with sites designed using Microsoft tools: support for FrontPage (Microsoft’s website-building tool, included with Office 2000) and Active Server Pages (Microsoft’s site scripting/application development framework with ODBC database connectivity). On Windows, the commercial option of Microsoft Internet Information Server (IIS) enjoys an obvious advantage, since it’s playing on its “home field,” built by its “home team.” Still, there is a free FrontPage alternative willing to put up a fight on Unix, as well as open-source and commercial alternatives for ASP and ODBC on Unix and Windows.
Commercial Option: Internet Information Server 5.0
Platforms: Windows NT, Windows 2000
Publisher: Microsoft, www.microsoft.com/windows2000/library/howitworks/iis/iis5techoverview.asp
Basically, IIS is the software that FrontPage and ASP were built to run with. Windows 2000 Server (which includes IIS 5) runs for about $950 – $1000 with a 10-client license. If you’re hosting on a Windows NT/Windows 2000 platform, this is a no-brainer. If, however, you’re hosting in a Unix (or anything else besides WinNT/2K) environment, IIS simply isn’t an option. There are no open-source alternatives I’m aware of for Apache/Win32.
Under Windows 2000, setup of IIS Server Extensions is pretty simple. After creating a new Web Site in the IIS administration interface, right-click on a site and select “Install Server Extensions.” A wizard will guide you through setting up the extensions for that host, including e-mail options (which you can set for that server or another mail host). After installation, you can select properties for that host’s server extensions through the “properties” dialog box by right-clicking on the host file.
Once they’re set up, IIS (at least in my experience) supports FrontPage extensions and ASP scripts very well and without much need for special administration. If (when) you experience problems, you should check out the FrontPage Server Extensions Resource Kit (SERK) at officeupdate.microsoft.com/frontpage/wpp/serk/. Note that IIS 5 also provides support for Active Server Pages and ODBC (see below) on the Windows platform.
Free Software Option: FrontPage Extensions 4.0 for Unix
Platforms: AIX, BSD/OS, FreeBSD, HP/UX, Irix, Linux, Solaris/SPARC, Solaris/x86, Tru64 (Digital)
Publisher: Ready to Run Software, www.rtr.com/fpsupport
The FrontPage Server Extensions for Unix (FPSE-U) version 4.x (version 3 was for FrontPage 98, 4.x is for FrontPage 2000) are available only for Apache on Unix platforms. These consist of an Apache module (mod_frontpage) and special binary server extensions that duplicate the publishing and server-side features offered by FrontPage. Note that I say this is a “free” software alternative, since it doesn’t cost you anything, but it isn’t open-source (sorry, Richard Stallman).
To install the FPSE-U, go to the Ready to Run Software site mentioned above, and download the extensions for your platform. These contain the FrontPage Server Extensions, the Apache module, and two installation scripts: fp_install.sh (to install the extensions on the server and for each required host/virtual host) and change_server.sh (to replace your Apache installation with a default one including the FP module). I strongly recommend that instead of running change_server.sh, you download the “Improved mod_frontpage” (home.edo.uni-dortmund.de/~chripo) and then compile your own Apache (following the instructions at www.rtr.com/fpsupport/serk4.0/inunix.htm#installingtheapachepatch), which will allow you to customize it and include the modules of your choice.
Once you’ve installed it, the FPSE-U generally work fine. You’ll need to learn to use the FPSE-U administration tool, fpsrvadm.exe, (check the FPSE-U SERK for documentation) usually installed into /usr/local/frontpage/currenversion/bin/, which generally isn’t much of a hassle. Note that I say “generally,” since (in my experience, at least) the FPSE-U have a habit of occasionally springing up weird errors which require a reinstall (especially as you try to support more FP users on Unix with more advanced requirements).
For troubleshooting, check out the RTR FrontPage 2000 documentation (www.rtr.com/fpsupport/faq2000.htm) and their message boards (www.rtr.com/fpsupport/discuss.htm) as well as the official FrontPage SERK (listed above). Note that the FPSE-U don’t provide any sort of compatibility for ASP or ODBC connectivity to Microsoft Access databases (which IIS/Win32 does, as do the ASP alternatives listed below).
Final Judgement:
This simply comes down to your choice of platform. If you’re running Windows NT/2000 Server, there’s no reason (you’ve already paid for it) not to use IIS for this. If you’re running any version of Unix, the free software alternatives are all you have. If you’re running Apache for Win32 … well, why are you running Apache for Win32?
Active Server Page (.asp) Support on Unix
Commercial Option: Chili!Soft ASP 3.x
Platforms: AIX, Solaris, OS/390, HP/UX, Linux
Publisher: Chili!Soft, www.chilisoft.com/ chiliasp/default.asp
ASP on Unix is already playing at a disadvantage, but for those wanting to support it on Unix hosting platforms (which have their own long list of benefits), it’s a necessary evil to deal with. Chili!Soft’s ASP product is relatively expensive ($795 for a single-CPU Linux or NT license; $1995 for Solaris, HP/UX or AIX). However, it seems to be reliable enough that IBM and Cobalt (recently purchased by Sun) have agreed to make Chili!Soft’s product an option on their server offerings; and, from most reports, it seems to work as advertised.
For all supported platforms, Chili!Soft offers a fully functional 30-day trial version at www.chilisoft.com/downloads/default.asp. Installation may require some pain-in-the-butt steps, but these are documented pretty well by going to www.chilisoft.com/caspdoc and following the directions for your platform of choice. After installation, things usually go pretty much as expected.
For support, you can check out their well-maintained forums (www.chilisoft.com/newforum), which offer frequent responses from Chili!Soft support employees, read their other documentation resources (www.chilisoft.com/support/default.asp), or call a phone number (for certain paid support packages).
ALTERNATIVES: These include HalcyonSoft’s Instant ASP [iASP] (www.halcyonsoft.com/products/iasp.asp), which is a Java-based solution that will run on any platform which supports a Java Virtual Machine (JVM). HalcyonSoft seems very committed to making their product available for as many platforms as possible, and offers a free “developer version” download. Note that for Win32 platforms, your commercial alternatives include Microsoft IIS, Chili!Soft ASP, iASP, and others.
Open-Source Option: Apache::ASP
Platforms: Any Unix platform supported by mod_perl (perl.apache.org)
Publisher: NodeWorks, www.nodeworks.com/asp
Apache::ASP is a Perl-based Apache module that works with mod_perl (with the common CGI.pm Perl module to handle uploads, and Perl’s DBI.pm/DBD.pm modules for connectivity to databases) to deliver ASP functionality. This module is heavily dependent on Perl, and the better you are with Perl, the better you will be with using and debugging Apache::ASP.
To install, find the latest version of Apache::ASP at http://www.perl.com/CPAN-local/modules/by-module/Apache/. Run Perl on the Makefile, then run a ‘make’ and ‘make install’ on the module (for more help, see www.nodeworks.com/asp/install.html). Additional resources for using Apache::ASP can be found at its homepage.
For support, try checking out the the Apache::ASP FAQ at www.nodeworks.com/asp/faq.html, or the mod_perl mailing list archives at www.egroups.com/group/modperl.
ALTERNATIVES: For more information on ODBC database connectivity through Perl’s DBI/DBD, see www.symbolstone.org/technology/perl/DBI (free) or www.openlinksw.com (commercial).
Final Judgement:
Since Apache::ASP works through Apache’s Perl module, be aware that its performance should be good, but, under heavy server loads, is unlikely to be as good as ASP support through a native binary (a similar concern exists for Halcyon’s Java-based iASP product). Apache::ASP is a good choice for basic installations or non-high-usage installations, but heavy usage, absolute mission-criticality or need for commercial-quality support will probably demand you use the Chili!Soft product (iASP provides commercial-quality support, as well).
Site Scripting Options
Commercial Option: Active Server Pages (ASP)
Platforms: Windows NT/2000, Windows 9x
Publisher: Microsoft, http://support.microsoft.com/support/default.asp?PR=asp&FR=0&SD=GN&LN=EN-US
Open Source Option: PHP Hypertext Preprocessor 4
Platforms: Most Unix platforms, Windows NT/2000, Windows 9x (See Apache platform information above for details)
Publisher: PHP Project, http://www.php.net
Overview:
As the Internet and the web have matured, CGI and dynamic content have rapidly replaced static HTML content for many sites. Unfortunately, as most developers will tell you, the increasingly complex requirements for dynamic sites have exposed many of the limitations of traditional CGI. However useful CGI was in extending the old infrastructure, it falls way short of current requirements for dynamic site design.
Quite a few software products are attempting to address the shortcomings of CGI and the desires of developers. They include products such as Microsoft ASP, Allaire ColdFusion, PHP, Apache ModPerl, and JSP, as well as others.
We’ll take a look at ASP and PHP, two popular scripting packages that, at first glance, appear to be very different beasts; but on closer examination, show a striking number of similarities.
ASP/PHP Common Features:
Script-Handling in the Web Server
One of the problems with CGI is that script execution usually requires the web server to spawn a new process in order to run the CGI script. The overhead of process creation is very high on some platforms. Even on platforms where it is efficient, CGI process creation can devastate performance on even moderately busy sites.
ASP and PHP have both sidestepped this problem by allowing the web server to handle the script itself. Neither one requires the web server to create an external process to handle a dynamic request. The script execution functionality resides in a module that is either built-in or dynamically loaded into the server on demand. The ASP functionality is part of Microsoft IIS, while PHP may be compiled directly into a variety of web servers including Apache and IIS. Although ASP and PHP handle this differently, the end result is more or less the same.
Session Handling
Due to the “stateless” nature of HTTP and CGI, it’s very difficult to “follow” a site visitor and keep track of his/her previous selections. As a kludge, developers have often posted data from page to page in hidden HTML form fields. This is neither convenient nor fail-safe, since it’s unwieldy and data can be lost between pages or compromised by malicious users.
ASP and PHP both have added support for “sessions.” A session allows the web server to simulate a continuous interaction between the user and the server. The server assigns the user a form of identification, and then remembers it and the data attached to it until the next request from that user arrives. Sessions minimize the amount of housekeeping work the developer must do to track the user across page requests. Again, ASP and PHP both provide good facilities for this.
Persistent Database Connections
Database access is a critical element for dynamic sites, providing a way to store and retrieve vast amounts of data that can be used to display tables of information, store user information/preferences, or control the operation of a site. A traditional CGI script has to connect to the database for each web request, query it, read the data returned, close the connection, and finally output the data to the user. If that sounds inefficient, it’s because it is.
To address this problem, ASP and PHP both support “persistent” database connections. In this environment, the web server creates a database connection the first time a user makes a request. The connection remains open, and the server reuses it for subsequent requests that arrive. The connection is closed only after a set period of inactivity (or when the web server is shut down). This is possible because the script execution environment remains intact inside the web server, as opposed to CGI where it is created and destroyed with the execution of each web request.
Again, this feature is a win for both ASP and PHP. Their syntaxes (though different) are simple and require no relearning of one’s database development knowledge.
Facilities for Object Design
A lot of useless information about Object-Oriented (“OO”) programming has been written, much of it presumably by people who either 1.) didn’t know what they were talking about, or 2.) were under the influence of Jack Daniel’s and horse tranquilizers. Here’s the real deal: OO design and programming allows you to encapsulate ideas in code through the combination of data and related data manipulation methods. Traditional programming has focused on the procedure that a program should follow, with data used as a “glue” to store information between and during procedures.
OO design focuses instead on the data and how it should act under different circumstances. This is done by housing data and function in distinct packages, or “objects,” that can’t interfere (except in predefined ways) with other objects. It is not a cure-all for poor programming, but it is a facility that allows for the creation of better software through good design and programming techniques. ASP and PHP both support the OO notion of classes (the definition of an object) in order to develop applications that are more modular, robust, and easier to maintain.
Access to External Logic Sources
Many designers would argue that for a truly complex installation, the site’s application or business logic should consist of objects completely external to the website and its presentation facilities. This is highly desirable since it allows you to build business objects that can be used for more than just your website and can be maintained apart from your site presentation code.
ASP and PHP allow you to access two types of external logic sources. The first, COM objects, are a Windows-based object framework. The second, CORBA, is a generalized network-transparent, architecture-neutral object framework. This support, especially of CORBA, is a huge win for both ASP and PHP.
ASP Features:
Ability to Utilize Different Programming Languages
When designing ASP, Microsoft made the decision not to tie the technology to a particular programming language. Although VBScript is what most people think of when they hear ASP, other popular language options include VBScript, Microsoft’s JScript, and PerlScript. This flexibility is especially useful if you or your development team has previous experience with one of these languages and your schedule precludes learning a new language for your current project.
Tight Integration with other Microsoft Software and Tools
For some, the ability to use Microsoft tools is a blessing; for others, a curse. For better or for worse, ASP is tightly integrated with other Microsoft tools. If you are comfortable with a Microsoft development environment, this could easily decide your scripting package for you. On the other hand, this tight integration can turn into a nightmare if you encounter insurmountable platform issues, as many Microsoft Windows tools do not have analogues on other platforms.
PHP Features:
Written Specifically As a Web Scripting Language
PHP benefits from being written from the ground up as a web-scripting language. It is tight and targeted, without the bloat that a general purpose programming language would have. This results in a package that is extremely stable, has a small memory footprint, and is lightning fast.
Integrates With Many Platforms and Web Servers
Version 4 of PHP was written using a new generalized API, which allows it to be ported more easily to other architectures and integrated into a variety of web servers, including Apache, Roxen, thttpd, and Microsoft’s IIS. It also is available for just about every type of UNIX as well as Windows 9x/NT/2000.
Final Judgement:
Both PHP and ASP have addressed many of today’s most critical web development needs. Both offer a ton of features, easy interfacing with all sorts of databases, and the facilities to create complex applications. For many, the decision will come down to a preference for one language or another, depending on what he/she has experience with already.
If the programming language is not a decision-making factor, the decision will probably come down to a choice of hosting platform. If you host on Windows, IIS/ASP is the obvious choice because of their tight integration. PHP operates quite nicely under Windows, but who in his/her right mind would turn down all of the resources Microsoft provides when working on its own platform? On the other hand, if you’re Unix-savvy, the decision to go with PHP is just as simple. PHP was born on Unix and built on top of Apache.
In the end, the question may not really be which solution is better, but which better fits the resources and needs of your project.
————————————————————————————————-
About the Authors:
Jeffrey Carl (Microsoft Web Compatiblity) is the Linux/BSD columnist for Boardwatch Magazine, and has written for the Boardwatch Directory of Internet Service Providers, CLEC Magazine and ISPworld. His writings have been featured on Daemon News, Linux Today, and Slashdot. He saw the plane dragging the “Web Hosting Magazine Kicks Ass” banner over the Spring 2000 ISPCON and agreed.
Matt Loschert (Site Scripting) is a web-based systems developer with ServInt Internet Services. Although he works with a variety of systems, programming languages, and database packages, he has a soft spot in his heart for FreeBSD, Perl, and MySQL. He begged Jeff to let him pretend to be a writer after hearing how cool Web Hosting Magazine was.
Eric Trager (Web Servers) currently serves as managing director for ServInt. With a background in personnel and operational management, Mr. Trager oversees ServInt’s daily business functions. His technical background includes four years in Unix server administration. He’s never read Web Hosting Magazine, but Matt and Jeff told him it was cool, so he foolishly believed them and wrote an article.