FP97: Resource Usage by FrontPage 97 Server Extensions on IIS

• Microsoft FrontPage 97 for Windows with Bonus Pack

SUMMARY

You notice greater resource usage within the Internet Information Server (IIS), versions 2.0 and 3.0, when you perform specific operations with the FrontPage Server Extensions. Resource usage increases as the number of FrontPage extended virtual servers and FrontPage subwebs increases or, in some cases, as the number of files contained within each FrontPage Web increases.

MORE INFORMATION

Following is a list of items that may cause excessive resource usage, particularly when the number of FrontPage extended virtual servers or the number of FrontPage subwebs on a given server is large.

Creating or deleting Root Webs, SubWebs, and Executable Directories

When you create or delete Root Webs, subwebs and executable directories, FrontPage reads and writes entries in the IIS Virtual Roots section of the Windows NT Registry. The Application Program Interface which IIS and FrontPage Server Extensions use to read and write these entries must read the entire list, append or delete an entry, and then rewrite the entire list. This causes noticeable delays when you create or delete Webs, or install extensions into new Webs. This also causes problems if multiple users author Webs at the same time. For example, one user may have the list of virtual roots locked for an update while another user attempts to write to it. Errors in the virtual roots of IIS as represented in Event Viewer or Internet Service Manager may slow down the process even further.

FrontPage creates seven to eight virtual roots per Root Web (depending on whether or not you already have a global mapping for "/cgi-bin") and six virtual roots per subweb. Since each FrontPage Web always defines these virtual roots, the more FrontPage Root Webs or subwebs there are on a given machine, the slower the performance of FrontPage authoring will be.

The best workaround to prevent this delay is to limit the number of virtual Roots and the number of FrontPage subwebs. In practice the number of virtual servers (and thus the number of Root Webs) is limited by spreading the virtual servers over multiple computers, but it is possible to limit the number of FrontPage subwebs allowed on a single computer. New FrontPage subwebs can only be created by FrontPage Administrators. Therefore, you can avoid creating an excessive number of subwebs (and virtual roots) by granting only authoring privileges instead of FrontPage administrative privileges to the users.

When you mark a directory as executable, a virtual root is created. For each directory you mark as executable, you add one virtual root. To prevent excessive delays in FrontPage Web performance, limit the number of folders marked as executable. One way to limit the number of executable directories is to establish a single, shared executable folder which contains the shared scripts. Any user who takes advantage of the shared scripts should reference the shared executable folder and therefore would not require individual executable folders.

You can limit the ability of FrontPage users to mark directories as executable by setting the NoExecutableCGIUpload=1 flag in the Frontpg.ini file.

For more information about the configuration variables used in the Frontpg.ini file, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q162145
   TITLE     : FP97: Configuration Settings for Windows NT Servers

Application of Permissions

IIS implements security on Webs through NT File System (NTFS) permissions. FrontPage Server Extensions apply permissions to a Web by checking the file system file by file. With each additional file in a FrontPage Web, the process of applying permissions to a Web takes more time. The more users and groups that are included in the permissions list, the more time it takes to apply permissions.

If permissions do not change frequently for a given Web, you should grant this privilege only to server administrators who can perform the permissions updates during non-peak hours or when truly necessary. Or, you can grant Authoring privileges to users to allow them to change content but not modify permissions.

If the list of users for a given Web changes frequently, you can achieve significant performance improvements by managing access to Webs through NT groups rather than through individual user account permissions. For example, you can establish a Windows NT group for browsers, one for authors, and another one for administrators of the Web. When you need to change Web permissions, modify the membership of the appropriate group in the Windows NT User Manager instead of updating the NTFS permissions for each file in the Web through the FrontPage Server Extensions.

Installing Extensions

When you install server extensions you also create virtual roots and grant file permissions, causing a delay in both of these activities. You can improve performance during installation by decreasing the amount of data in the content area of the server where you are installing the server extensions. However, those performance gains are mitigated when you bring the intended content back into the Web again. You can also enhance performance by installing the server extensions during non-peak hours when server demand is decreased.

Busy Web Server

If the Web server is heavily used, the FrontPage Server Extensions may not be able to successfully complete a resource intensive operation like publishing a Web. Note, however, that there are many other reasons why publishing may not complete successfully, such as unreliable modem connections to the Internet.

To work around this problem, establish a schedule where you publish your Webs during non-peak hours when the server is not managing resource intensive operations. As a further precaution, you may be able to use staging servers to alleviate heavy loads on the production server used for FrontPage authoring.