What's New In IIS 6.0: A Practical Administrative Guide (Part 2 of 2) : Page 2
The first article in this two-part series explored IIS 6.0's new features. This part of the series concentrates on the "hands on" activities to implement and manage those new features. You'll see how to configure IIS 6.0 to leverage Web services extensions, enable ASP.NET processing, and troubleshoot some new IIS 6.0 issues.
by Chris Peiris
Sep 25, 2003
Page 2 of 5
Working with ASP.NET
ASP.NET is the most recent version of Microsoft's Active Server Pages technology. IIS 6.0 lets you run both the previous ASP version (classic ASP) and ASP.NET applications simultaneously. ASP.NET code runs on the .NET framework, while the classic ASP scripts run using the older Windows Component Object Model (COM). The ASP.NET model is scalable and performs better than the classic ASP model. You can use classic ASP scripting inside ASP.NET scripts, but you're generally better off to use "code-behind" which separates programming logic from the HTML code needed to display the content in a browser. You're no longer limited to VBScript or JScript, either; you can create ASP.NET applications in any .NET-compatible language, such as C#, VB.NET, Jscript.NET, J#, etc. Before you can run ASP.NET on IIS though, you must first enable ASP.NET support from the Web service Extensions management console. You need to follow these steps:
Navigate to Start | Administrative Tools | IIS Manager.
Click on Web Server Extensions node on a selected server name. Figure 1 is similar to a default view of the Web service extensions window.
Select the ASP.NET option from the Web Service Extension window. You can click on the Allow or Prohibit button to enable or disable ASP.NET access.
Author's Note: If the IIS server does not recognize a ASP.NET file (.aspx file extension) the server will return the static text content of the aspx file as the response rather than invoking the ASP.NET engine and processing the aspx file properly. This can happen if you reinstall IIS without reregistering ASP.NET. New IIS 6.0 installations are not automatically ASP.NET-enabled; therefore, you have to re-register ASP.NET after installing or reinstalling IIS.
Assigning Resources to Applications
You can assign resources to applications in different ways. The most common way is to select the application, and then use the Properties dialog to control caching, performance and process options.
You can use IIS's bandwidth throttling option to restrict resources for a given application. (You can find the bandwidth option under the Performance section in the Properties dialog.) The maximum (and default) bandwidth value is 1024 KB per second. You can enable bandwidth throttling by selecting the Limit the network bandwidth to this Web site check box and specifying a maximum kilobytes per second value. You can also limit the number of connections to the Web site by using this Performance tab. Select either the Unlimited or Connection limit to option button and specify a connection value.
Worker Process Recycling and Impact on Session Data
One of the reasons classic ASP became instantly popular is because it made maintaining data for individual browser instances much simpler by introducing the concept of Session data. ASP used a unique server-generated HTTP cookie value to connect a specific browser instance with information stored on the server concerning that browser instance's activities. ASP sessions timed out if 20 seconds elapsed without a new request from a specific browser, but otherwise remained valid as long as IIS was running.
In contrast, IIS 6.0 works on a worker process model; when the worker process stops you lose all the session information. The default installation configures IIS to recycle a given worker process every 120 minutes. But there's a problem. Under certain abnormal conditions, the recycle process can cause your ASP.NET applications to lose Session data. So why does IIS 6.0, by default, recycle processes at all? The answer is that by refreshing the worker process every so often, IIS ensures that even if bad code or memory leak errors slow down or tie up the worker process, the application itself will eventually refresh and remain available (under a new process) for users. In addition, recycling worker processes ensures that a single leaking or rogue application won't permanently affect the server.
You can limit the possibility for Session data loss if you run out-of-process Sessions (such as storing Session data in SQL server). When you do that, shutting down a process has no effect on the data stored for any particular Sessionwhich is why Microsoft recommends that you store session state externally. Under normal conditions, recycling gives the active worker process an allotted (configurable) time interval to finish its current requests. Session data loss will occur only if the active worker process refuses to shut down within the allotted interval.
If you find that the recycling process affects your application, you can either disable worker process recycling or increase the timeout value of the application shut down interval to solve the problem. Here are the steps,
Open IIS Manager
Select Application Pools and right click on the correct application pool for your Web site
Select Recycling tab
To disable worker process recycling uncheck the Recycle worker process (in minutes) option. Alternatively you can select the option and enter a figure to extend the time in the text field. (see Figure 2)