Gallery

Configuring ASP.NET

Posted on 20 Feb 2006 at 12:07

Thomas Lee looks at how to manage and configure ASP.NET, together with IIS and HTTP

Mindful of HTTP's stateless nature, the designers of .NET implemented several features to simplify the developer's job when dealing with state. While these features are mainly of interest to application architects and developers, they do possess an administrative aspect - system admins can configure certain aspects of state management via config files, as I'll describe later.

IIS

IIS is Microsoft's web server, although, in fact, it's a lot more than just a simple web server - IIS is also an application server that enables you to build, deploy, and manage web apps. IIS has been supplied as a free add-on to the Windows Server platform ever since its first release. IIS 3 and 4 were supported by Windows NT 4, although they weren't included as part of the OS, but had to be downloaded as an independent package. IIS 5 was released as an integral part of Windows 2000 Server and, interestingly, it got installed by default whenever you installed any of the Windows 2000 Server editions - an unfortunate state of affairs that malware writers later exploited (two of my own servers got hit this way). The latest version, IIS 6, ships with Windows Server 2003, but nowadays isn't installed by default.

Active Server Pages

In the early versions of IIS, in order to build a web app you had to rely on the use of CGI (common gateway interface), which was created in the Unix world. This involved writing a program or script that would be launched to process each individual HTTP request and to return a reply (while managing state as necessary). It was a complex business, and thanks to NT's process architecture was slow, as it had to spawn a new process for every request.

Active Server Pages (ASP), introduced with IIS 4, offered web app developers a much simpler and significantly more productive way to implement rich and dynamic websites and web apps. ASP was essentially a client-side scripting approach, where an app is implemented using one or more related .ASP web pages. Each .ASP page may contain a mixture of HTML, which gets rendered within the client browser, and server-side scripts that process the HTTP request returned from the client and generate the dynamic output. For example, an ASP page that's part of a stock-control app might accept a part number via the client browser interface, then use an ASP script to perform a database lookup for that part, finally generating a new page that shows up-to-the-minute inventory levels for that part and returning this to the browser. The ASP script gets interpreted over again for each page hit, which poses an obvious performance issue, but for small to medium-sized web apps the gain in developer productivity more than made up for the performance hit - fast hardware was cheap and people less so.

IIS 6

IIS 6, Microsoft's latest version, ships with Windows Server 2003 and features a new web server architecture. In IIS 5, if a single web app falls over, other sites and apps running on the same server might be affected. Under IIS 6 by contrast, web apps are isolated into units called Application Pools, which separate the apps into different memory spaces on the same server.

Using IIS 6's MMC management snap-in, you can configure one or more distinct Windows processes, known as worker processes, to serve each Application Pool. On large multiprocessor systems, you can enable a single-worker process to spawn at most two processes, which in effect limits each app to run on a maximum of two CPUs. Worker processes operate independently, so if one fails it doesn't affect other worker processes. Application Pools provide increased reliability, greater availability of websites and apps, and a useful increase in the number of separate websites and apps that can be run on a single server.