A client server?

It is a bit strange for a product that has the word “services” in its name to have a client version, but basically the “client” variant of the Internet Information Services was released with Vista, and “server” will come with Windows Server 2008, hopefully later this year. The “server” version is presently available as a release candidate, and can be downloaded with WS2008. Martin did not go into much detail about the differences of those two versions, but he said that the client has limited functionality and throughput. The good news is that the limitation of a single web site, that bugged web developers on Windows XP with IIS 6, is now removed.

As the demonstration switched from Vista to a virtual WS2008 server to show the new management console and diagnostics features, I can only suppose that such features are not yet integrated into the “client” version.

Modular architecture

What was before w3svc is now split into two services. W3svc still exists, but it only deals with the HTTP kernel driver. The rest is in in the Windows Process Activation Service (codename WAS), which is further modularised into the Configuration manager, Process manager and Listener adapter interface. The responsibilities of the first two modules are pretty clear from their names, but the third module is a real novelty. It uses the Windows Communication Framework to allow plugging various listeners into the pipeline, so that requests can come across HTTP, but also raw TCP, named pipes or MSMQ message queues.

When the request comes in, it is sent through the request pipeline. This is where the biggest difference from IIS 6 comes into play — a modular architecture of the request pipeline. It looks like IIS7 is completely rewritten in .NET, because it enables developers to replace any part of the request pipeline with a custom module, written either in .NET or native code. Although .NET HTTP modules were supported in IIS6, the request had to come under the ASP.NET domain to use such flexibility, and you could not really replace standard functionality for authentication or logging or inject something into the pipeline without writing an ISAPI extension. Now, ASP.NET HTTP modules are truly utilised to the full extent. If you want, you can remove any standard module and replace it with your own, and do all that in .NET.

This gets even better — if you write a module in .NET, it does not have to be globally active or installed for the whole server. It can be loaded from web.config in a web application folder, so no special administrative privileges are required to change the pipeline.

Native modules and ISAPI extensions are still supported, but they have to be registered on the server level and have to be defined globally. You can, however, prevent the worker process from loading them for your application.

One more good thing about this is that the standard pipeline is now broken down into a number of DLLs, and you can actually prevent the system from loading any one of them. With IIS6, they were all in three big DLLs and loaded by default. Excluding modules that are not required will help lock down the server better, so this is a good security feature.

No more metabase

Another nice new feature of IIS 7 is that the configuration is now truly modularised. The big metabase is gone — and is now replaced with a system-wide text file called applicationHost.config (the IIS equivalend of machine.config) and web-site or folder local configuration in web.config files. The good news is that web.config can now override any setting. That includes modules, as I’ve already mentioned, but also error handlers, MIME mappings and all the other stuff that had to be edited in the metabase earlier.

The new administration console supports “delegation” — giving privileges to administer parts of the site or certain options to individual users. This works even with HTTP authentication of non-windows users, so you no longer have to open a local system or domain account for individual web site administrators. Any activity can be marked as not delegated, read-only or read/write for a particular user, and the user’s view is trimmed according to permissions. The console can even work remotely over HTTPS. All these improvements should appeal to people using shared hosting services or maintaining a large number of web sites.

Better diagnostics

IIS7 comes with something called “runtime status and control API” which allows developers to programmatically access diagnostic information about the running server. Lots of information on application pools and active requests should be available via this API, and it is also accessible within the IIS admin tool. Martin showed a demo of that tool, quickly displaying all active requests, their details and information on worker processes. The console even displays the module that is currently executing the request, which will be great for troubleshooting.

For better problem-solving, IIS7 also supports “failed requests tracing” (codename FREB). That basically comes down to dumping lots of tracing information into files only if certain conditions are met, such as status code, timeout or a generated trace event of a specific severity. The XML result contains the whole pipeline, duration of every executed step in milliseconds, exception information and a lot more. This feature does have performance implications (as tracing is buffered for all requests, and then only flushed if the trigger condition is met), and has to be enabled on the web site level. So I guess that it should not be used for general alerting, but only turned on when a serious problem is being looked at.

First impressions

IIS7 seems like a nice idea, especially the modularised pipeline, and I see how it could help us do our work faster. I’d like to see the production version and its performance before passing final judgement, but the demo really looked prommissing.

One thing that is notably missing, at least in my opinion, is the ability to run services that are not request-based. For more complex background processing, IIS7 still requires a windows service and the web application will have to use IPC to talk to it. Microsoft PR seems to have moved from the claim that IIS is an application server, with IIS 7 now presented as a “web application server” rather than an “application server” as was IIS6, so it does not seem likely that we will soon get the option to start a background service and chat with it from the web layer without the overhead of IPC and switching from managed mode.

For more information on the upcoming release, see Microsoft’s new IIS portal, IIS.NET.

Image credits: Karl-Erik Bennion

The primary aim of caching is to speed up processing and reduce load on critical resources. In case of web sites, the most critical resource is probably going to be the database – so dataset caching is a common solution to speed up the web. It is relatively easy to implement, and it can be introduced almost transparently into an existing system. But that is just painting the corpse. First of all, dataset caching requires the same source data to be re-processed over and over, and takes up unnecessary CPU cycles. Also, a lot of data from recordsets is often not displayed directly, so dataset caching can lead to a lot of wasted memory – in fact, I’ve seen sites where this approach caused serious problems by fragmenting memory under heavy load and leaving the application without enough memory to run.

Although the web site will, no doubt, benefit significantly even from a dataset cache, it will scale much more and better if the cached content is closer to the final product. How much closer, that depends on the application. The golden rule of web caching is: For the caching to be most effective, cache as close to the final product as possible.

Ideally, cache content into static files

The best option for caching, if possible, is to use static files on the disk and allow web servers to publish those files directly. All web servers will process static files very efficiently, and that will also leave more resources for stuff that needs to be processed dynamically. Content on the disk does not take up valuable memory space available for the web application, and it absolutely minimises CPU requirements per request.

Here are the results of a stress test I recently did on a fairly good web server machine running IIS6 over a gigabit network. I measured the number of requests per second during a two-minute stress load for serving the a couple of files using several techniques.

• Static – file served directly by IIS from disk
• ASP-SSI – file included using #include SSI directive in an ASP file (turning on the SSI engine)
• ASP-Include – file included using #include SSI directive in an ASP file but with an ASP statement if (true) around the include (so turning on the ASP engine as well)
• ASP-Cache – file read from disk using FSO, but cached in an Application object for up to 10 seconds.
• ASP-Nocache – file read from disk on every request using FSO
• ASPX-SSI – file included using #include SSI directive in an ASPX file
• ASPX-Include – file included using #include SSI directive in an ASPX file, with an additional C# if (true) block around the include
• ASPX-Cache – file read from disk but cached using ASP.NET page caching for 10 seconds
• ASPX-NoCache – file read from disk on each request, page caching turned off

The difference between “static” and “aspx-cache” is the pure overhead of using the ASP.NET engine. For a 4KB file, we get a 38% increase of performance from a file based cache over even the ASP.NET page caching mechanism. Compared to a simple cache based on the Application object in ASP, the performance increase is 150%. And this is just for managing completely static content. A typical web application would pull the content from a database or format it, leading to much bigger differences. Also interesting is the difference between ASP-Include and ASP-SSI, effectively the cost of having turning on the ASP engine (having if(true) statement in ASP code). The good news is that difference between those two cases in ASP.NET is negligible.

With larger files we hit the bandwidth bottleneck first, so the benefits of a file based cache are not that visible. However, with the growing number of Ajax-based sites, pages are getting split into smaller independent requests, and so the overhead becomes quite noticeable. Although ASP.NET page caching is a great utility given that it almost requires no work to implement, file based cache can also be split across the server farm, allowing multiple machines to use the same content.

Caching into static files also brings the benefit of automatic support for last modification timestamps. For browsers with HTTP 1.1 support, if the same files are downloaded often (live Ajax updates), the server can actually reply just with the “304 Not modified” header, without sending any file content at all. Cache that works directly from disk files also allows us to use lightweight HTTP servers such as LightHTTPD to get some extra performance from the same hardware.

Not just for pre-publishing

The file based cache is often used for pre-publishing content, but there is a simple trick to use this technique for on-demand publishing, even for content that must be generated often on the fly. Most web servers I have worked with, including IIS and Apache, will allow us to override the 404 “Not found” handler. This can be used to implement the cache-miss scenario: when users request a file that has not yet been cached, IIS will not find it on the disk and will call the 404 handler; we can then generate the file using dynamic processing (ASP/ASP.NET) and store it to the disk for the next request before sending the content back to the client. The same technique can be used with Apache and PHP.

An important note for this technique is that requests must be mapped completely to the file path of the URL, not to GET parameters. So, for example, instead of using http://myserver/search.aspx?query=fitnesse, we would have to use something like http://myserver/search/fitnesse.query. Then a 404 handler would be set up on the search folder to perform a search based on the active URL path and store it into the fitnesse.query file. You can generally chose any extension you want, but avoid ASP/ASPX and other standard extensions, to prevent IIS from turing on ASP/ASP.NET processing when serving those files. HTML and TXT extensions are also not a good choice. IE uses “smart” caching by default, so HTML files are downloaded just once per page. If you fire a background AJAX request twice for a HTML file, only the first will actually go to the server. TXT and HTML files may also be cached by transparent proxy systems, so it’s best to avoid using those extensions.

Image credits: Akis Kolokotronis/SXC