To establish application permissions, place your script files in separate
directories associated with the application. You can set script access on these
directories and use other directories for .htm and other files that need read
access. This approach protects the script directories from having read access,
and protects the other file directories from using script access. This
configuration prevents users from placing executable scripts in any directory
except the script directories.
After you create a directory or virtual directory that you want to use as a
Web application, you must change the AppRoot property setting to point to the
directory or virtual directory; otherwise, IIS won't treat the directory or
virtual directory as an application. Open ISM, and go to the Application
Settings section at the bottom of the application's Properties dialog box to
configure the AppRoot property setting. To set the AppRoot property, click
Create. I entered NTMag into the Name text box, and clicked Create (after you
set the AppRoot property, the Create button becomes the Remove button, as you see in Screen 2).
When you create a Web application, IIS uses MTS to add the application to
the IIS In-Process Applications package. You can see the IISWAM.1_ROOT_NTMag entry in the package, as Screen 3 shows. This is the entry for your new Web
application. The IIS In-Process Applications package runs all in-process
applications in the IIS process space (netinfo.exe). This behavior is the same
in IIS 3.0 and IIS 4.0.
You can change this behavior by selecting the Run in separate memory
space (isolated process) check box under the Application Settings section of
the application's Properties dialog box. When you select this option, IIS uses
MTS to create a new package and move the Web application into the new package. I
selected the Run in separate memory space (isolated process) check box,
and refreshed the packages in the MTS Explorer. Screen 4 shows that IIS has
removed the application entry (IISWAM.1_ROOT_NTMag) from the list in the
left pane of the MTS Explorer. When I changed the isolated process setting, IIS
created the new MTS package, IIS-{Default Web Site//Root/NTMag}, which you see
in Screen 4. That package contains the Web application and runs in a separate
memory space.
If you run the Web application and use Task Manager to watch the system
processes, you notice that isolated applications use a few CPU resources from
inetinfo.exe. However, the application is running in the mtx.exe (a part
of MTS that executes the application) process space. As a result, mtx.exe uses
the most resources.
Because isolated applications run in a separate memory space, they perform
slower than non-isolated applications. When a process running in one memory
space (such as inetinfo.exe) needs to communicate with a process in another
memory space (such as mtx.exe), the operating system (OS) must go through an
extra, resource-intensive step known as marshalling to facilitate the
communication between the two applications. As a result, the application's
performance degrades significantly.
So, if isolated applications run slower, why use them? Four good reasons to
isolate an application in a separate memory space are
- You want to prevent an application that is misbehaving from bringing down
IIS.
- The application is in development, and you want to protect IIS from
application problems.
- You need to change components in the application over several days without
stopping IIS.
- The application is using MTS components that you're testing.
If you isolate an application, you must monitor the server and the
application to ensure that the performance doesn't degrade to the point where
the application is unusable. You can use tools such as Performance Monitor, Task
Manager, and MTS Explorer to monitor applications.
When a user requests a page from the Web server, IIS inspects the URL to
determine whether the file type maps to an executable. If so, IIS passes the
page to the Web Application Manager (WAM), which manages each application, and
the WAM invokes the appropriate executable to handle the file. If you look at
Screen 3 and Screen 4, you notice that each application has the string WAM
in its name. If you look at the properties for a Web application, you will see
that the entry maps to the c:\winnt\system32\inetsrv\wam.dll.
ASP map to the asp.dll processor you see in Screen 5. These mappings are
the default settings for files in a Web application. By looking at these
mappings, you can see how IIS maps various file types to a processor. If you
change these settings, IIS will no longer use the default processor for files in
that particular application. You can enable mappings for an Internet Server API
(ISAPI) extension or Common Gateway Interface (CGI) program by adding entries to
the list, or remove mappings by deleting entries.
Prev. page
1
[2]
3
next page 
