docs.intersystems.com
Home / Web Gateway Configuration Guide / IIS Technical Notes

Web Gateway Configuration Guide
IIS Technical Notes
Previous section           Next section
InterSystems: The power behind what matters   
Search:  


For those interested who use IIS, this appendix describes application pools, web gardens, and bitness.
IIS Application Pools and Web Gardens
Application Pools
An application pool is a configuration that links one or more applications to a set of one or more worker processes. Because applications in an application pool are separated from other applications by worker process boundaries, an application in one application pool is not affected by problems caused by applications running in other application pools.
By creating new application pools and assigning Web sites and applications to them, it is possible to make the server more efficient and reliable. Applications working through pools are always available, even when a worker process serving a different application develops a fault.
Applications are defined by their path in IIS. For example: /csp
Web Gardens
For even greater reliability, it is possible to configure an application pool to be supported by multiple worker processes. An application pool that uses more than one worker processes is called a web garden. The worker processes in a web garden share the requests that arrive for that particular application pool. If a worker process fails, another worker process can continue to process other requests.
It should be noted that web gardens are different from web farms. A web garden is configured on a single server by specifying multiple worker processes for an application pool. Web farms use multiple servers for supporting a web site.
Creating a web garden for an application pool can enhance performance in the following situations:
Application Pools, Web Gardens, and CSP
Application Pool and Web Garden configurations do not affect the operation of NSD-based Gateway configurations because the ISAPI module communicating with the NSD does not pool any persistent information or other resources (such as connections to InterSystems IRIS™). All persistent resources are held in the NSD module. The ISAPI module communicating with the NSD is unaffected by changes in the way it is managed by IIS.
The non-NSD based Gateway configuration (CSPms.dll and CSPmsSys.dll) is more sensitive to changes in the way ISAPI extensions are managed in IIS because the pooling of persistent resources (such as connections to InterSystems IRIS) takes place in the extension itself.
Application pools that are configured to use no more than one worker process have no visible impact on the way the Web Gateway operates within the context of a single web application path (for example, /csp). However, for configurations where multiple worker processes are used (a Web Garden) the workload for the Web Gateway is evenly distributed amongst all participating worker processes in the pool. Each worker process manages its own instance of the Web Gateway modules. This process management architecture does not pose a problem with respect to the way the Web Gateway operates but the following restrictions must be borne in mind:
Note that the NSD-based options are not subject to these restrictions because the Web Gateway is managed independently of IIS.
Finally, the effect of certain worker process configuration parameters on the non-NSD version of the Web Gateway should be considered. In particular, the effect of the idle timeout and process recycling facility should be borne in mind.
Idle Timeout for Worker Processes
Often it is necessary to conserve system resources by terminating unused worker processes. It is possible to configure a worker process to gracefully close after a specified period of time. This feature can be used to better manage the resources when the processing load is heavy, when identified applications consistently fall into an idle state, or when new processing space is not available.
When a worker process is terminated, the instance of the Web Gateway that it manages also closes, and the pool of connections to InterSystems IRIS held by that Gateway instance is terminated. Of course, additional stateless connections can always be replaced in a way that is transparent to users of a web application, but state-aware sessions (preserve mode 1) terminate when their hosting connection is closed.
Recycling Worker Processes
IIS can be configured to periodically restart worker processes so that faulty web applications can be recycled. This facility helps to ensure that application pools remain healthy and that any leaked system resources are recovered.
It is possible to configure worker processes to restart based on elapsed time, number of requests served, scheduled times, and on the basis of memory usage.
The effect on the Web Gateway of closing worker processes was discussed in the previous section (Idle Timeout). The same considerations apply here. Because web applications can only interact with the Web Gateway through carefully managed channels, it is recommended that worker processes supporting the web applications should not be recycled.
Bitness — 32-bit Apps on 64-bit Servers for Windows
Note:
This section applies to modules that are loaded into the address space of the hosting web server: ISAPI Extensions and Native Modules (CSPms[Sys].dll and CSPcms.dll). CGI modules are not affected since they run as a detached process with respect to IIS.
The Enable 32-Bit Applications setting applies to the Application Pool level, which makes it possible to set the bitness for a particular Application Pool. In a single server installation, you can configure one Application Pool to run native 64-bit applications and another to run 32-bit applications.
To access the bitness setting for an Application Pool, enter the IIS control panel:
  1. Select Application Pools in the left hand panel.
  2. Select the appropriate Application Pool.
  3. Select Advanced Settings in the right hand panel.
  4. The Advanced Settings dialogue appears. The Enable 32-Bit Applications setting is found in the General section. This can be set to True or False.
Incidentally, this configuration setting can be manipulated at the Windows Command line using the appcmd command. For example:
appcmd set apppool /apppool.name:DefaultAppPool/enable32bitapponwin64:true
This sets the Application Pool DefaultAppPool to run in 32 bit mode.
It is also possible to list the Application Pools based on bitness using the appcmd command. For example, to list all the application pools running in 64 bit mode use the following command:
appcmd list apppools /enable32bitapponwin64:false
Finally, since application pools can be run in different bitness modes, it is necessary to ensure that Native Modules (and ISAPI extensions) that are loaded by the Application Pool are themselves of the correct bitness for the pool. For example, if the hosting application pool is 64-bit, then the 64-bit Gateway modules (such as CSPms[Sys].dll) must be used. If the hosting Application Pool is 32-bit, then the 32-bit Gateway modules must be used instead.
The bitness check for individual modules is done via a preCondition in the module’s web.config file. For the Web Gateway, this file typically looks something like the following:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <add name="WebGateway_All" path="*" verb="*" modules="CSPms" resourceType="Unspecified" \
             preCondition="bitness64" />
        </handlers>
        <security>
            <requestFiltering>
                <hiddenSegments>
                    <remove segment="bin" />
                </hiddenSegments>
            </requestFiltering>
        </security>
    </system.webServer>
</configuration>
Note the bitness setting in the precondition clause. In this case bitness is set to bitness64 which means that IIS checks for 64-bit Gateway modules operating in a 64-bit Application Pool.
If a 32-bit Application Pool is used, then the 32-bit Gateway modules must be used and the preCondition set to bitness32.
If there is an inconsistency between the modules installed, the precondition clause, and/or the expectations of the hosting Application Pool, IIS returns an error condition similar to the one shown below.
Error:
The module(s) assigned to this handler mapping has the following preconditions that are not
present in the handler mapping:
bitness64
Runtime errors may occur if a handler mapping does not have a set of preconditions that are
equally as restrictive as, or more restrictive, than the module(s) assigned to the mapping.
Please ensure that this handler mapping has the correct preconditions, and that the 
preconditions are not in conflict.


Previous section           Next section
Send us comments on this page
View this book as PDF   |  Download all PDFs
Copyright © 1997-2019 InterSystems Corporation, Cambridge, MA
Content Date/Time: 2019-07-17 06:06:47