IIS 6 Administration

You now have a pretty good idea of the big picture of IIS 6 architecture, especially the two different application isolation modes and how they operate. But there are a few more architectural features of IIS 6 we haven’t discussed yet, and I’ll close the chapter by discussing these briefly.

Logging

Earlier versions of IIS included the ability to log HTTP requests in various text-file formats including native IIS format, NCSA standard format, and W3C Extended format. Requests could also be logged directly to an ODBC-compliant database or logging could be handled by installing a custom logging module (usually implemented as COM components). IIS 6 includes all the same logging capabilities but implements them differently. In IIS 5, for example, logging of all types was handled by the core inetinfo.exe process. In IIS 6, however, different processes handle logging:

• IIS, NCSA, and W3C Extended logging are performed by the Kernel Mode HTTP Listener http.sys.

• ODBC and custom logging are performed by individual worker processes instanced by w3wp.exe.

The advantage of moving text-based logging to the kernel is not only better performance but also the elimination of concurrency issues where several applications try to write to the same log file simultaneously. Such concurrency leads to thread blocking and thus performance degradation. This has been eliminated in IIS 6 and is another reason the current version performs better than earlier ones. Concurrency is usually not an issue with ODBC logging, however, since the database applications to which such logs are written are typically designed to manage concurrent access themselves.

However, problems could arise if custom logging modules designed for earlier versions are used with IIS 6. These are overcome by the fact that when IIS 6 is configured for either ODBC or custom logging, it automatically disables its kernel mode caching. Furthermore, when using custom logging modules, you should not implement web gardens or overlapped recycling, and you should make sure that all applications belonging to the website to which you wish to log are configured as belonging to the same application pool.

Caching

I mentioned earlier that http.sys also maintains an in-memory kernel mode cache for both static and dynamic content retrieved from IIS. This kernel mode cache, called URI response cache, is intelligently implemented using advanced heuristics that determine which content is worth caching and which should be discarded. Items that can be returned from cache take advantage of the higher privilege level of the kernel mode http.sys process and essentially bypass IIS entirely. In other words, when http.sys receives an HTTP GET request for a cached item, it immediately returns the item without transitioning the processor to user mode. Everything takes place in kernel mode, which makes performance very fast for cached content.

Also, as I discussed earlier, http.sys caches incoming HTTP requests, routing them to kernel mode queues mapped to corresponding application pools. So http.sys implements two kinds of in-memory kernel mode caches, one for incoming HTTP requests (in the kernel mode queues) and one for outgoing HTTP responses (in the URI response cache). You can even modify the size of the kernel mode queues by editing the metabase, allowing you great flexibility in tuning IIS performance. The URI response cache does not have a caching policy implemented by http.sys, however. Instead, web application developers can define caching policy programmatically.

Caching is also implemented in another form in IIS 6, namely, with regard to Active Server Pages (ASP). When an ASP page is requested by a client, the scripting engine compiles the ASP code into an intermediate form called an ASP template. These templates are stored in an in-memory cache for reuse purposes, a feature that was supported by IIS 5. In fact, IIS 6 can cache up to 250 ASP templates in-memory, and this number can be modified by editing the metabase. What’s also new in IIS 6 is that once this in-memory cache of templates becomes full, the oldest items are not simply dropped as they were in IIS 5. Instead they are persisted to disk, that is, cached offline for later use if required. This new feature can significantly improve the performance of ASP applications running on IIS 6 as compared to previous versions.

Large Memory Support

For memory-intensive applications like large database applications, the IIS 6 in-memory cache can be configured to utilize up to 64GB of physical memory. This feature is called Large Memory Support and greatly increases the scalability of IIS 6, making it a suitable platform for running even the most demanding mission-critical line-of-business web-based applications.

64-Bit Architecture

Finally, the code for IIS 6 in particular (and Windows Server 2003 in general) is compiled to run on both the standard 32-bit x86 processor platform and the newer 64-bit Itanium platform. The 64-bit version of IIS 6 has the same architecture as the 32-bit version described in this chapter.

You plan on migrating your IIS 5 web applications to the new IIS 6 platform. You're not sure if these applications will run properly on IIS 6, so naturally you plan to install them on a testbed IIS 6 system first before moving them to a production system. When testing your applications, should you run IIS 6 in worker process isolation mode or IIS 5 isolation mode? What are the advantages of running IIS 6 in worker process isolation mode where possible? What sort of IIS 5 applications are likely to break when run on IIS 6? Are the enhancements in IIS 6 significant enough that you might consider rewriting code to ensure it runs in worker process isolation mode instead of using IIS 5 isolation mode?