Handling Requests in Load-Balanced Environments

  • Article

In load-balanced environments, all client requests are subject to load balancing. Load balancing presents some unique challenges, because all requests sent to a cluster might not benefit from load balancing. For example, requests to deploy applications must be processed by the controller. Otherwise, application deployment on members will be overwritten by synchronization. Clients who have established session state must also have their requests processed by particular members. Otherwise, clients can experience disruption in their sessions if their requests are load balanced to a member on which the session information does not exist.

To forward HTTP requests to particular members in load-balanced environments, Application Center provides the request forwarder. The request forwarder ensures that the following types of requests are forwarded to the controller:

  • Internet Information Services 5.0 (IIS) administration requests.

  • Microsoft FrontPage® publishing.

  • Web Distributed Authoring and Versioning (WebDAV) publishing.

  • Web-based administration requests.

Maintaining Session State

The request forwarder provides generic support for maintaining session state by using cookies to associate clients with particular members. Subsequent requests containing the cookie are forwarded to the appropriate member.

For example, if a client creates a session on member A, subsequent requests might be load balanced to member B. Because member B might not have the appropriate session information (thus disrupting the session), the request forwarder sends subsequent requests to member A by using information supplied in a cookie.

By default, request forwarding is enabled for only sites that use Active Server Pages (ASP) session state. These sites have session state enabled as an option under Application Configuration in IIS. The alternative is to enable request forwarding for all Web sites.

Request forwarding might slightly impact performance because the request forwarder processes requests after they have been load balanced; it does not eliminate load balancing for any requests.

Generally, the best performance is achieved by eliminating the Web cluster from having any involvement with session state. For example, you can keep session information in a Microsoft SQL Server™ database while state is maintained in a client's cookie. Since the Web cluster does not manage session state, you can disable or remove the request forwarder.

You may also want to disable or remove the request forwarder to optimize Web clusters that do not use ASP session state.

Optimizing Performance

Request forwarding imposes minimal overhead as it forwards requests. To minimize performance degradation, you can disable request forwarding for certain file types. To bypass request forwarding for a certain file type, see Exclude Specific File Types from Request Forwarding.

Request Forwarder Implementation

The request forwarder exists as an ISAPI filter and extension. If other ISAPI filters are unaware of request forwarding and require the services provided by the request forwarder, install these filters after installing the request forwarder filter. You can install ISAPI filters that do not require request forwarding before installing the request forwarder filter. With ASP sessions that don't use cookies, the cookie handler must be installed before the request forwarder filter.

By default, the request forwarder limits the number of concurrent requests that can be forwarded to 50. You can change this value in the metabase as described in Knowledge Base (KB) article 281439. To function properly, the request forwarder should exist on all members or on no members. Unpredictable behavior can result if you install the request forwarder on some members and not on other members.

As a cluster receives client requests, the request forwarder considers the URL, virtual directory, file name, and file type of each request. From this information, the request forwarder determines whether to forward the request:

  • If the request is for a static file, it will not be forwarded.

    You can use the cluster Properties dialog box to specify which file types are static and do not need to be forwarded.

  • If the request is for a dynamic file, the request forwarder checks the request for a cookie.

    If it finds a valid cookie, the request forwarder detects the status of the target. If the target is online and alive, the request is forwarded. If the target is offline or inactive, the request is processed locally and the request forwarder removes the session identifier from the cookie.

    If the request forwarder cannot find a cookie in the request or the cookie is invalid, the request forwarder creates a cookie that identifies the current server.

  • If the request is a FrontPage or WebDAV publishing request, it is forwarded to the controller.

Bb687544.note(en-us,TechNet.10).gif Note   The request forwarder supports only one Secure Sockets Layer (SSL) site per IP address because it uses host headers to determine the destination member for forwarding (and these headers are encrypted in HTTP requests). For more details, see KB article 262780.

Did you find this information useful? Please send your suggestions and comments about the documentation to acdocs@microsoft.com.