Table of Contents Previous Section

Load Balancing

When you deploy a WebObjects application, you will probably want to improve performance by distributing the processing load among multiple instances of the application. This application processes can be running on the same machine as the server or on remote machines. The task that accomplishes this distribution is called load balancing.

You perform load balancing by creating a public configuration file named WebObjects.conf and manually starting an application for each instance described in the file. When the adaptor receives an HTTP request for an application, it first (in its initial mode) checks WebObjects.conf for an application instance that is accepting connections and forwards the request to it. The public configuration file can contain entries for instances of multiple applications and multiple instances of the same application running on different machines. The section "HTTP Adaptors" describes in some detail both the public configuration file and the adaptor modes involved in load balancing.

Note: Load balancing is possible only with the WebObjects Enterprise product. The feature is not supported in the WebObjects Pro product.


Making the Public Configuration File

The following steps describe the composition of a typical public configuration file using some WebObjects applications found in DOCUMENT_ROOT/WebObjects/Examples.

  1. Using a text editor (such as the TextEdit application), create an ASCII file named WebObjects.conf.

  2. Insert the lines of configuration information in WebObjects.conf needed by the adaptor to interact with application instances. Each line must conform to this format:

    ApplicationDirectory:InstanceNumber@HostName PortNumber

    For example, say you want one instance of the HelloWorld application to run on host toga.acme.com. You might make this entry: 

        Examples/HelloWorld:1@toga.acme.com 3001

    There are several things to note about the parts of a WebObjects.conf entry:

    You cannot omit any part of an entry.

    Of course, to be useful, the public configuration file should describe multiple instances of the same application and perhaps other applications as well. The following example shows load balancing among two hosts (togo.acme.com and tutu.acme.com) and two applications (HelloWorld and CyberWind). 

        Examples/HelloWorld:1@toga.acme.com 3001
    Examples/HelloWorld:2@toga.acme.com 3002
    Examples/HelloWorld:3@toga.acme.com 3003
    Examples/HelloWorld:4@tutu.acme.com 3001
    Examples/HelloWorld:5@tutu.acme.com 3002
    Examples/CyberWind:1@toga.acme.com 4001
    Examples/CyberWind:2@tutu.acme.com 4001

    When the adaptor gets a request, it tries to resolve the request's URL against the entries in the public configuration file until it finds an application it can contact. Thus, if a user submits the following URL: 

        http://toga.acme.com/cgi-bin/WebObjects/Examples/CyberWind

    and the CyberWind application instance on the server machine (toga.acme.com) is already processing a request, it will contact the application instance 2 of CyberWind on tutu.acme.com.

  3. Save WebObjects.conf in the location or locations appropriate to the platform and adaptors (specified directories are relative to the server root):
    MachSolarisHPUXWindows NT
    CGIcgi-bincgi-bincgi-bincgi-bin
    NSAPIn/ahttpd-port/config
    or
    https-port/config    		httpd-port/config
    or
    https-port/config    		httpd-port/config
    or
    https-port/config
    NSAPI2n/ahttpd-port/config
    or
    https-port/config    		httpd-port/config
    or
    https-port/config    		httpd-port/config
    or
    https-port/config
    ISAPIn/an/an/a D:\WINNT\
    System32
    (D = drive letter)
    Note: If you are using WebObjects Release 3.1, you can save the WebObjects.conf file in the directory <NextRoot>/NextLibrary/WOAdaptors/Configuration regardless of which adaptor you are using. WebObjects 3.1 is backwards compatible with WebObjects 3.0, so storing WebObjects.conf under the server will still work.


Running the Applications

You must manually start each application instance specified in WebObjects.conf from a separate shell program window on the host indicated by the WebObjects.conf entry. For each instance, go to the appropriate machine and start a new shell (on Windows NT, use the Bourne Shell program provided in the WebObjects program group). When you give the command, make sure the command line names an adaptor class (WODefaultAdaptor is the default) and specifies port and instance-number arguments that match the entry in WebObject.conf. The following example---for a Netscape 1.1 server on Windows NT and using the default adaptor class---corresponds to the first entry in the example above. The command would be given from a shell on host toga.acme.com: 

    C:\NeXT\NextLibrary\Executables\WODefaultApp -a WODefaultAdaptor -n 1 -p 3001 
	-d C:/NETSCAPE/ns-home/docs Examples/HelloWorld

If the application directory (the last argument) is on a remote machine rather than on the same document root as the server, and you want load-balancing to be transparent, you'd specify the document root (the path after the -d flag) of that remote WebObjects machine. Note that the remote document root doesn't have to mirror the document root on the server machine. The following would be an acceptable command: 

    C:\NeXT\NextLibrary\Executables\WODefaultApp -a WODefaultAdaptor -n 1 -p 3001 
	-d C:/WOApps Examples/HelloWorld

For this command to be valid, however, you'd have to create on the remote machine a subdirectory in C:\WOApps called WebObjects and install the HelloWorld application in that subdirectory. Note that the Examples directory is unnecessary, but to get load balancing to work properly you'd have to modify the entry in WebObjects.conf appropriately and move HelloWorld from the Examples directory up to DOCUMENT_ROOT/WebObjects: 

    HelloWorld:1@toga.acme.com 3001

See "Manually Starting WebObjects Applications" for more about the arguments of this command.

Table of Contents Next Section