Chapter 2: IIS 6 Architecture

In the previous chapter, we looked at the new features and enhancements Microsoft has incorporated into their latest version of IIS. These enhancements are intended to increase the security, reliability, scalability, performance, and manageability of the platform.

This chapter complements the previous one by providing an in-depth examination of the internal workings or architecture of IIS. Understanding this information is crucial to being able to effectively deploy, configure, manage, monitor, maintain, and troubleshoot IIS web applications in the real world.

The Evolution of IIS Architecture

The inner workings of IIS have evolved a great deal since the initial version IIS 1 was released in February 1996. In fact, the internals of IIS have undergone significant redesign several times. It will help you understand the enhancements and new features of the current version IIS 6 if we trace the evolution of IIS architecture from the early days to today. I touched on some of the new architectural features of IIS 6 in the previous chapter and will now cover them in detail.

Prior to IIS 4

The original architecture of IIS could best be described as monolithic: everything was based on in-process execution. In other words, a developer who wanted to write a web application would typically use Microsoft’s Internet Services Application Programming Interface (ISAPI) and the C programming language to write DLLs that would add dynamic functionality to their website. These DLLs would then be loaded into the main IIS web server process (inetinfo.exe) and run within that process. This was very different from the original UNIX web server model, as you’ll see next.

ISAPI was developed for IIS 1 as the Windows NT alternative to the Common Gateway Interface (CGI) of UNIX web servers. CGI uses an out-of-process execution model whereby a CGI application (typically a Perl script) runs within its own CGI process, separate from the web server process or Httpd daemon. While CGI works well enough for simple applications like form handlers (the code that handles information submitted from a form on a web page), performance is usually poor because each time a CGI application is invoked, a new instance of the CGI application is started on the web server. So, if a site with a form is experiencing heavy traffic, it is possible that a dozen or more instances of the same CGI process might be simultaneously running on the server, each consuming its own memory resources. The process of creating and destroying CGI processes also consumes processor and memory resources, further degrading performance and limiting CGI’s ability to scale.

Because CGI scaled so poorly, Microsoft developed the ISAPI approach based on in-process execution as an alternative. In-process means that an ISAPI DLL runs within the main web server process inetinfo.exe, not within its own separate process as in the CGI model. Like CGI, these ISAPI DLLs can be loaded into memory when needed and unloaded when no longer required. Unlike CGI, however, a single ISAPI DLL can satisfy requests from multiple clients simultaneously (in the CGI model, a new CGI process must be started to handle each client request). This means that ISAPI applications are more scalable because they use memory more efficiently than CGI does. Another advantage is that the overhead of constantly switching between processes (a problem with the CGI model) is eliminated, because IIS also allowed ISAPI DLLs to be loaded into memory at server runtime.

On the whole, ISAPI was a terrific idea and made IIS a powerful platform on which to develop dynamic web applications. For example, ISAPI filters could be used to preprocess HTTP requests from web browser clients to perform functions such as customized authentication, access control, and logging. An ISAPI filter is an ISAPI DLL that receives an HTTP request, processes it in some fashion, and then forwards it to the World Wide Web Publishing Service (WWW Service) for further action. ISAPI filters could also be used to post-process HTTP responses received from the WWW Service before they are returned to the browser client. Alternatively, ISAPI applications could be written to enable database lookups from web pages. In this scenario, the client sends an HTTP request that’s received by the WWW Service and passed to the ISAPI application. The application then uses the Internet Database Connector (IDC) to issue a query against the database. It receives a response and forwards this response to the WWW Service, which returns the result to the client (the IDC is now legacy technology, having been replaced by ADO and other technologies). See Figure 2-1 for an illustration of how ISAPI worked in early versions of IIS.

Figure 2-1: The in-process execution model of IIS 1, 2, and 3.

Note 

ISAPI applications were often called ISAPI extensions because they “extended” the functionality of the WWW Service, making IIS a more powerful platform than one that simply served up static HTML pages. IIS also supported the CGI model used by UNIX to make it easier for developers to port web applications written with Perl scripts from Apache to IIS. However, Microsoft recommended using ISAPI wherever possible because of its greater scalability and better performance. IIS 2 also included another programming model called server-side includes, which supported only the #INCLUDE directive and not #EXEC (this is rarely used now so we won’t discuss it here).

This all sounded great in theory, but in practice ISAPI was difficult to use because it generally required C programming expertise to develop the appropriate DLLs. (By contrast, Perl, used in CGI programming, is an interpreted scripting language and is much easier to learn than C.) Another, more serious disadvantage was that one malfunctioning ISAPI DLL could bring down the entire web server and require a reboot to correct. This was particularly frustrating for developers, as C programs are often difficult to debug, and there was no way of isolating a buggy application from other ISAPI applications running on the server.

Microsoft then introduced a powerful new model for developing dynamic web applications with IIS 3. This new model was called Active Server Pages (ASP) and involved combining ActiveX scripts with ActiveX server components to create powerful web applications using scripting languages like Visual Basic Scripting Edition (VBScript) and JScript (an offshoot of Netscape’s JavaScript). In fact, both these scripting languages were developed by Microsoft primarily for use in ASP on IIS 3, and the resulting IIS/ASP combination rapidly soared in popularity. It remains the most popular way of developing web applications for IIS today. VBScript in particular enabled Microsoft to leverage the talent of millions of Visual Basic programmers around the world, giving them a brand new platform to develop applications for: the Internet.

The architecture of IIS remained essentially unchanged in version 3 with the introduction of ASP, because ASP itself was implemented as an ISAPI extension called Asp.dll. This meant, however, that ASP on IIS 3 suffered the same problems that other ISAPI applications experienced, which was that one malfunctioning ASP application could bring down the entire server. While the in-process execution model of IIS 3 increased performance of web applications, it decreased reliability because ASP applications also ran within the same inetinfo.exe process as the WWW Service. However, this was about to change with version 4 of IIS.

IIS 4

IIS 4 was the first version of IIS to undergo a significant change in its internal architecture. There were two significant changes that occurred in IIS 4, which involved both how web applications ran and how IIS configuration information was stored:

• Web applications such as ASP scripts and ISAPI extensions could now optionally be run out-of-process from the main web server process inetinfo.exe. With IIS 4, you could specify which applications should be loaded in-process with inetinfo.exe and run in the same process as the WWW Service, and which applications should run in their own separate processes (see Figure 2-2). This new feature was known as process isolation and could be used to enhance the stability and reliability of IIS applications because an application running out-of-process could fail without affecting the running of other in-process applications on the server. Essentially, process isolation allowed IIS to maintain the performance advantage of ISAPI and ASP while providing the stability of GGI. I’ll talk more about process isolation in a moment.

  
  Figure 2-2: The dual architecture of IIS 4 allowed applications to run in-process or out-of-process.

• Most IIS configuration settings were moved from the Windows Registry where they were in previous versions to a new memory-resident data store called the metabase. The reason for this was performance: the metabase was faster, more flexible, and more easily expanded than the Registry. The only IIS configuration settings not migrated to the metabase were those Registry keys involved in starting up IIS services, plus a few others for maintaining backward compatibility with earlier versions of IIS. I’ll talk more about the metabase in Chapter 14, “Working with the Metabase.”

Process Isolation

The ability of IIS 4 to run applications out-of-process offered several advantages compared to the monolithic in-process execution model of previous versions:

• An out-of-process application that crashed had no effect on other applications running on the server. This was different from the monolithic architecture of earlier versions where all applications ran in-process with the main IIS process, and the crash of one application meant all applications went down on the server.

• An out-of-process application could be stopped and restarted independent of other applications on the server without affecting the other applications. This simplified the task of application maintenance on IIS. For example, if a component of an isolated web application needed to be updated, the application could be stopped, upgraded, and restarted without affecting anything else running on the server. This was great for administrators who needed to upgrade web applications with as little downtime as possible.

• An out-of-process application could be configured to restart automatically after it failed. If an in-process application failed, the entire web server was down until inetinfo.exe could be restarted or the server rebooted.

The downside of process isolation was that out-of-process applications tended to run much more slowly than in-process ones. This meant that process isolation was mainly suited toward testing and debugging applications on IIS. Once they were bug-free, they could be moved in-process for better performance. Another disadvantage was that out-of-process applications could not access IIS metabase properties using built-in IIS admin objects (this could be worked around but was not recommended for security reasons). Finally, out-of-process applications consume more memory resources than in-process ones. Every ASP application running in its own process requires resources to run; and if you needed to run a dozen of them on a single machine, you would need a very large machine!

Note 

Process isolation on IIS 4 was a feature of ISAPI applications, which included ASP applications. It was not a feature of ISAPI filters, however, as these could only be run in-process.

MTS and WAM

The ability to run web applications out-of-process within their own separate memory space was made possible because of the integration of Microsoft Transaction Server (MTS) into the IIS 4 architecture. MTS worked as a middle layer that provided automatic thread and process management for IIS components. A component of MTS called the Web Application Manager (WAM) was responsible for enabling IIS applications to run out-of-process. The WAM was essentially a COM wrapper that could be used as a container for ISAPI functionality. In other words, web applications like ISAPI extensions and ASP pages were wrapped in WAM objects, which themselves were hosted by the MTS runtime environment and registered as COM objects by MTS. The WAM object encapsulated all the ISAPI functionality of the application, enabling the appropriate ISAPI DLL to be located and loaded when required (each IIS application had its corresponding WAM object in one-to-one fashion).

The MTS Executive (mtxex.dll) ultimately hosted all of the web applications on the IIS machine, whether they ran in-process (within inetinfo.exe) or out-of-process (within an MTS proxy process called mtx.exe spawned by the IWAM_computername account). The WAM Director received each incoming HTTP request and forwarded it to the appropriate MTS package, as shown in Figure 2-3.

Figure 2-3: A more-detailed look at IIS 4 architecture including the WAM and MTS

By default, on IIS 4 all applications were initially configured to run as in-process applications. Once an application was installed on the server it could be configured to run out-of-process by selecting the Run In Separate Memory Space (Isolated Process) check box on the properties sheet for the application’s virtual directory (see Figure 2-4). Selecting this check box caused IIS to automatically create a new MTS package for this application and run it within the proxy mtx.exe process.

Figure 2-4: Configuring an IIS 4 application to run out-of-process within its own isolated memory space

Note 

Process isolation in IIS 4 applied to dynamic web content (ISAPI extensions or ASP pages) only. All static web content was serviced by the core inetinfo.exe web server process, regardless of what application it was a part of.

IIS Admin Service

I should mention here one additional under-the-hood component of IIS 4, the IIS Admin Service. This service acted as a kind of manager of all other IIS services, and these services, like the World Wide Web Publishing Service (WWW Service or W3SVC, a component of inetinfo.exe), FTP Service, SMTP Service, and NNTP Service all are dependent on the IIS Admin Service. In other words, stopping the IIS Admin Service stops all these other services as well. The IIS Admin Service is also responsible for maintaining the metabase.

IIS 5

Microsoft again changed the architecture of IIS in version 5. The reason was that the process isolation feature of IIS 4 had an additional limitation I haven’t mentioned: an out-of-process web application could not communicate with any other applications on the same machine. Unfortunately, certain types of applications needed to cooperate with each other, and this was impossible in the IIS 4 model unless such applications ran within the core web server process (inetinfo.exe), which of course affected stability and reliability of the server. Clearly, something different was needed, and the architecture of IIS was modified to meet this need.

Whereas IIS 4 offered only two levels of application protection (in-process and out-of-process), IIS 5 was designed to provide three different levels of application protection:

• Low (IIS Process) The application runs in-process as part of the core web server process (inetinfo.exe) as in the original monolithic architecture of IIS versions 1–3.

• Medium (Pooled) The application runs out-of-process from inetinfo.exe as a separate pooled process, that is, as one of several applications running within a new COM+ host process called dllhost.exe.

• High (Isolated) The application runs out-of-process alone within its own isolated dllhost.exe host process.

  Note 

  The newer COM+ architecture of Windows 2000 means that all out-of-process IIS 5 execution takes place within surrogate dllhost.exe processes instead of the mtx.exe proxy processes used in MTS 2 on IIS 4. These dllhost.exe processes are spawned by the same IWAM_computername account used in IIS 4.

The Medium (Pooled) option was new to IIS 5, and it allowed multiple ISAPI and ASP applications to run within a shared memory space for greater cooperative interaction between them. Note that the Medium and High options use out-of-process execution while Low is in-process. The advantage of this new architecture was that pooled out-of-process applications run with better performance than isolated out-of-process applications. Also, while a single IIS machine could typically host only a dozen or so isolated applications (because of the huge memory requirements), it could host hundreds or even thousands of pooled ones. Figure 2-5 shows the revised architecture of this version 5 of IIS.

Figure 2-5: IIS 5 could run applications in-process, as a pooled process, or as an isolated process.

Note 

An obvious disadvantage of running thousands of sites or applications within a single pooled process is that if one application crashes, the entire pool goes down. Microsoft anticipated this problem, however, and IIS 5 was structured so that when the pool went down, it automatically restarted when the next request sent to any application in the pool was received. Windows 2000 also included a new feature called the Service Control Manager (SCM) that provided automatic recovery options for services that failed, allowing IIS services to be restarted without user intervention when a crash occurred. For example, the IIS Admin Service can be configured to restart or a reboot can occur should the service fail. Finally, administrators could manually run a command-line utility called iisreset.exe to restart IIS 5 after a crash. With all these various options, IIS 5 was certainly a more robust and reliable platform for web application development than previous versions!

Medium (Pooled) was the default setting for all applications on IIS 5, which meant by default the web server process inetinfo.exe ran by itself, serving up static content while all dynamic web applications ran within the same pooled process. When a new application was created, it was automatically assigned to this pool and could be moved to an isolated process or made part of the core web server process by selecting the Application Protection list box on the properties sheet for the application’s virtual directory (see Figure 2-6). Note that this could only be set at the application’s starting-point directory (you needed to define the application starting point first).

Figure 2-6: Selecting the Application Protection level in IIS 5

The main problem with the IIS 5 architecture was the issue of performance. Appli- cations running with Low (IIS Process) application protection ran in-process with inetinfo.exe and performed well, but led to instability because a failed application could bring down the core web server process. For greater reliability, either Medium (Pooled) or High (Isolated) application protection could be used, but this often led to a performance penalty, particularly when an out-of-process web application had to retrieve an ISAPI server variable from the core inetinfo.exe process. To accomplish this, data marshalling had to be used, an inherently slow procedure that employed RPCs over COM between the WAM process and inetinfo.exe. As you’ll see shortly, the new architecture of IIS 6 eliminates this bottleneck with the result that out-of-process applications run much quicker on IIS 6 than they did on IIS 5.

Note 

Microsoft recommended in IIS 5 that inetinfo.exe be run as its own separate process with no applications configured in it. This way a single application failure can’t bring down the entire web server; even if all dynamic applications crash, the server can still serve up static HTML content. Applications that are either under development or mission-critical should be run as isolated processes, while all remaining applications can be run within the pooled process for greater performance. Microsoft further recommends that the number of isolated applications be limited to ten or less to reduce the impact on web server performance these applications have.