Server Selection and Load Balancing Using the SAP
Web Dispatcher 
Uses
The SAP Web Dispatcher forwards each incoming HTTP(S) request to an appropriate SAP Web Application Server for processing, as illustrated in the following graphic.
The SAP Web Dispatcher carries out the following tasks:
· Checks the session ID to pass subsequent requests for stateful sessions to the processing server.
· HTTPS scheduling or end-to-end SSL
· Decides whether the request is an ABAP request (e.g. a BSP application) or a Java request (e.g. a JSP or a servlet).
· Balances load
Process
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 J2EE server. It determines a group of servers in the SAP system that could execute the request. The SAP Web dispatcher gets the details about the groups from any application server. (Compare Server Groups in ICF).
2. The load is then balanced within this group. When it has been decided which server the request is sent to, the SAP Web Dispatcher forwards in to the ICM if it is an ABAP request; and directly to the J2EE Dispatcher if it is a J2EE request (see J2EE Cluster Architecture)..
Determining the Server Group
How the SAP Web dispatcher determines the server group that will process the request is described here.
Working with Logon Groups in the SAP System
If the request should be sent to an SAP Web AS, 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.
Since with HTTP there are many requests, this logon group must have the attribute “external RFC” so that no one server is flooded with requests.
Load Balancing in the Server Group
Static Load Balancing Process
Capacity is assigned to every application server. With the SAP Web AS ABAP server, this depends on the number of dialog work processes. In the case of the SAP J2EE engine the capacity depends on the number of server processes. The requests are distributed in turn 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.
YYou You can configure the details of the load balancing process in the profile parameter wdisp/load_balancing_strategy. The following tables shows the differences:
Load Balancing in the SAP Web Dispatcher
|
Process |
weighted_round_robin (default) |
simple_weighted_round_robin |
|
Description |
The requests are distributed in turn to the servers, depending on their capacity.
|
Each server with capacity w receives precisely w requests in succession, before the next server takes over. |
|
Advantages and Disadvantages |
Better balancing, especially with end-to-end SSL
|
Better performance (with more than 20 systems) The process, especially with end-to-end SSL could lead to unexpected results, if many individual servers have to process too many successive requests. Requests received. |
|
Example |
There are two servers, A and B. Server A has twice the capacity as server B (A has six dialog work processes, B only has three). The requests are distributed as follows: |
|
|
Request 1 ® A Request 2 ® A Request 3 ® B Request 4 ® A Request 5 ® A Request 6 ® B … |
Request 1 to request 6 ® A Request 7 to request 9 ® B Request 10 to request 15 ® A …
|
|
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 J2EE requests, each HTTPS-enabled server must have integrated the J2EE server.
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 J2EE server.
See also: