Show TOC

Process documentationServer Selection and Load Balancing Using the SAP Web Dispatcher Locate this document in the navigation structure


The SAP Web Dispatcher forwards each incoming HTTP(S) request to an appropriate SAP NetWeaver Application Server for processing, as illustrated in the following graphic.

This graphic is explained in the accompanying text.

Forwarding of Requests by the SAP Web Dispatcher

The SAP Web Dispatcher carries out the following tasks:

  • Checks the session ID to pass subsequent requests for stateful sessions to the processing server (Session-Stickiness).

  • Decides whether the request is an ABAP request (e.g. a BSP application) or a Java request (for example, a JSP or a servlet).

  • Load Balancing

  • HTTPS scheduling or end-to-end SSL

  • URL filtering


First of all, the SAP Web Dispatcher checks the type of the incoming request (see Processing Administration Requests).

The process flow described below only works if the request is not an administration request.

An HTTP request (or a decrypted HTTPS request) is assigned to a server in two stages. HTTPS requests with End-to-End SSL are dealt with last in this section.

  1. First, the SAP Web Dispatcher decides whether the incoming HTTP request should be forwarded to an ABAP or a Java server. It determines a group of servers in the SAP system that could execute the request. It gets the information about the groups from an application server.

    For more information, see:

    AS ABAP: Server Groups in ICF

    AS Java: Configuring Logon Groups on AS Java

  2. The load is then balanced within this group. When the load balancing process has decided on the server that the request is to be sent to, the SAP Web Dispatcher forwards it to the ICM of this application server.

Determining the Server Group

How the SAP Web Dispatcher determines the server group that will process the request is described under Determining the Server Group.

Working with Logon Groups in the SAP System

If the request should be sent to an AS ABAP, then you must check whether a logon group (maintained in transaction SMLG) has been defined for this URL. The SAP Web dispatcher checks the list of logon groups to see if one has been defined. If it finds one, the load balancing must be executed within this logon group.

Load Balancing in the Server Group

Both static and dynamic elements are used for load balancing with the SAP Web Dispatcher. The Web Dispatcher provides various procedures for load balancing. The Capacity of an application server is an important factor. The capacity is a measure of the “power” of an application server.

What procedure is best for your application depends on many factors. Normally, the standard procedure (weighted round robin) leads to a balanced load distribution. If you think that a different procedure would improve the load distribution, you can change the procedure with parameter wdisp/load_balancing_strategy.

The following load balancing procedures are configurable:

Simple Weighted Round Robin

Parameter value: simple_weighted_round_robin

Each server with capacity k receives precisely k requests in succession, before the next server takes over. The requests are distributed in turn (“round robin”) to the instances depending on their capacity. If server A has twice as much capacity as server B, then A will receive twice as many requests as B.

This process is simple and deterministic since it contains no dynamic elements.

Note Note

This process, especially with end-to-end SSL could lead to unexpected results, if many individual servers have to process too many successive requests.

End of the note.
Dynamic Weighted Round Robin

Parameter value: weighted_round_robin (default)

The load is balanced using an estimation of the current load (“load factor”). The server with the lowest load factor receives the next request. If a server is assigned a request, the load factor is increased in proportion to the reciprocal value of the server capacity. The load factor can be display in the Web Administration Interface. Since the load factor is constantly changing, the information about the next preferred server is simply a snap-shot situation.

This process has the advantage that load balancing on the server is very good, especially with end-to-end SSL.

The process contains another dynamic element: For every application server the Web Dispatcher knows the number of requests that the server still has to process. This information also flows into the server selection.

Fully Dynamic Load Balancing Using Server Response Times

Parameter value: adaptive

To estimate the current load of a server (determine the “load factor”), the actual response times to the “ping” requests sent periodically to each server are used (instead of fixed predefined capacity values). The smaller the response time (in milliseconds), the smaller is the increment of the current load factor for each request.

Server Selection and Load Balancing for HTTPS Requests

Since with End-to-End SSL HTTPS requests the SAP Web Dispatcher is unable to read the URL, it can only distribute HTTPS requests in turn to the HTTPS-enabled servers in the system. This also takes into consideration the capacity of each server. To be able to process Java requests, each HTTPS-enabled server must have integrated the AS Java. The ICM of the server that receives the HTTPS request can decode the URL and then decide whether the request should be sent to the ICF or to the integrated Java server.