This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 . It is not the current version, and thus it cannot be edited.

Back to current versionRestore this version

LOAD SHARING AND SEPARATE REPORT SERVER#

Overview#

This page will explain how to alleviate application performance issues by deploying multiple applications in parallel to make better use of server resources, improve stability and reduce downtime.

The most common sources of performance problems are situations where large reports are being run and where many users are logged into the application simultaneously. Both cases can consume excessive server memory and processing power in certain situations, resulting in other application services slowing down while the server works harder to manage a heavier load.

Typically, one application is deployed into an Oracle Application Server(OAS) instance and each instance has a dedicated memory allocated and can be allotted to run on specific processing 'cores' of the server. Therefore, deploying multiple applications in parallel and automatically distributing logged-in/online users evenly over these applications will reduce the memory consumed by each application, while increasing the processing power available to each instance.

Similarly, large Windward reports consume a lot of memory and processing power when building report output files. Deploying an application which only launches and manages reports, in parallel to an application which only handles online-users, will prevent resource-intensive reports from affecting online users, and allow administrators to finely tune the memory allocated to report processes.

While neither of these features are mandatory to run the application, one or the other can be used, or both as needed. For example, users with large processing needs may choose to have four load sharing application instances and one report server application instance pointing to a single database.

Both features use some common logic and configuration is similar. There are a few differences with set up, and they are noted below.

Separate Report Server#

• Deploy an application instance to launch and process all reports
• Automatically forward report launching, running and scheduling to correct instance
• Scheduled reports must be run by Report Server instance
• Report status feedback information on report forms must be maintained
• Only one report server should exist for each database
• Requirement is that this instance is given higher system memory (heap size)
• Divide services & watchers between application and report server appropriately
• Limit number of reports to run simultaneously and schedule others (Queuing)
• Remove unneeded packages from report server EAR file

Load Sharing#

• Deploy multiple applications in parallel to evenly share load of users
• Automatically forward users logins to available instances in 'Round-Robin' pattern
• Do not rely on connection information saved on client - check server for every login
• Implement Oracle specifications to support Clustering/Load Balancing

Common Features#

• Feature should not be mandatory (i.e. only used as needed)
• Number and location of application instances must be configurable
• Configuration file on server file system specifies available applications
• Configuration file should be monitored to allow for dynamic updating without restarting applications
• Login as normal and system will forward requests between available instances

A very configurable deployment options have been built to take advantage of these two features. A simple configuration file can define the location and quantity of instances used, whether they exist in the same application server, or completely different machines on the network. After a new instance is deployed, modifying the configuration file is all that is needed to redirect clients to the correct application server.

Application Implementation#

Connections#

There are two types of connections made when launching the application:

1. A link on a web server must be visited in order to download several files which include the java archive (JAR) files containing the appropriate code, JARs containing pictures, icons and configuration files, as well as a JNLP file.
2. The JNLP file contains the information to make the second connection to the application server, through which all application communication is routed thereafter. A sample of this part of the JNLP file is included below:
   

<application-desc main-class="com.highlinecorp.professional.EPersonality">
       <argument>PORT=12411</argument>
       <argument>SERVER_IP=http://phobos.highlinecorp.com:7779/ePersonality_AS06</argument>

The simplest way to implement load sharing and a separate report engine was to alter this connection information and route the application traffic to the desired server. In other words, most of the changes to support these features were done on the client side connection logic.

Configuration File#

A configuration file has been created on the server which contains a comma-separated list of all available application instances as well as a report server instance. A sample of the file is included below:

#Format: reportHost=xxx|port,yyy|port
epHosts=http://phobos.highlinecorp.com:7779/ePersonality_AS06@12411,http://phobos.highlinecorp.com:7779/ePersonality_AS06@12412
reportHosts=http://phobos.highlinecorp.com:7779/ePersonality_AS07@12413

A system administrator can add to the list in this file as more instances become available, or restrict the list in this file, and changes are picked up in a matter of seconds. This can reduce downtime by redirecting clients to another instance whenever a new EAR is deployed, or if there is ever a problem with the server and it needs to be restarted.

Servlet#

A small Java servlet was built into the application to 'serve up' this information to applications when users want to connect. The servlet will iterate over the list for every login, such that the first user logging in will be directed to the first server in the list, the second user login will be directed to the second server in the list, and so on. The servlet will continually repeat through the list in an effort to distribute online users evenly over the available applications. Each client will also retrieve the report server information, in the event they wish to run a report at any time during their session.

The servlet can be tested by opening (the following sample) URLs in a web browser and refreshing to get new connection information saved in the configuration file:

http://phobos.highlinecorp.com:7779/selfService_AS06/loadsharingservlet?type=ep
http://phobos.highlinecorp.com:7779/selfService_AS06/loadsharingservlet?type=report

Client Side#

When launching the application, three connections are made, the first to download the JARs and JNLP, the second to connect to the servlet and retrieve information to make the third connection to the server which will handle all application communication. The second step also receives connection information to a report server, and a fourth connection may be made if the user launches a report during their session.

Essentially, another step has been added between the original two connections to contact the server and get the correct connection information from the configuration file.

Set Up#

Deployment Types#

The same EAR can be used for all three types of deployments:

• Load Sharing
• Report Server and
• Stand Alone applications

An example of a stand-alone application is one application instance to one database. With the exception of stand-alone applications, all instances must define the deployment type as one of the following JVM arguments:

-Dcom.highlinecorp.deployment=application (for load sharing applications)
-Dcom.highlinecorp.deployment=reportServer 
-Dcom.highlinecorp.deployment=standAlone 

Instance Options#

Load Sharing instances can be deployed in several ways.

For example, if a user wishes to use three instances for load sharing, they could deploy;

• One instance with three Java Processes (JVMs),
• or three instances could be deployed with one JVM each,
• or the user can mix and match (e.g. two instances with one and two JVMs respectively)

An instance with multiple JVMs has the feature of reduced work when deploying or restarting an instance since the action needs to be done once by an administrator and the Oracle AS will duplicate the work for every other JVM.

However, the drawback is that JVMs cannot be restarted or redeployed individually, causing all application processes to be down (mix and match option may solve this).

Report servers must have a completely separate instance with one JVM.

Report servers should not have any startup cache loaded - configured in AppResources/selfServiceStyle.xml

Configuration File Location#

A file named connections.config must be created for every application deployment and modified by the system administrator to reflect the available deployments. The applications listens for changes to this file and they are picked up in a matter of seconds.

This file can be placed in the same root directory as the JNLP file. To override this, you may also specify a file locations as a JVM argument using:

-Dcom.highlinecorp.connections.config=/server_path/connections.config

Changes to JNLP file#

Since the RMI port is now retrieved from the servlet when the client side application starts up, there is no need to add it into the JNLP file. However, if a PORT argument is in the JNLP file, it will be used to connect to the same RMI port every time. (i.e. It will use the old implementation to connect to the server and no load sharing or separate report server will be accessed, even if they exist.)

Also, note that when using this servlet, the SERVER_IP argument has changed to use the selfService context. The relevant JNLP file portion now looks like this:

   <application-desc main-class="com.highlinecorp.professional.EPersonality">
       <argument>SERVER_IP=http://phobos.highlinecorp.com:7779/selfService_AS06</argument>

The JNLP file SERVER_IP argument is now used to find the connection information servlet.

File Attachment Folders#

If the report server is setup on a different machine, the file attachments folder must be accessible to this server as well in order to save and retrieve report output files. In this case, the network path must be specified rather than the local machine path to the directory on the IMST Preferences tab.

Suggested Deployments#

Every instance can be placed on a different machine, or they can all run within the same application server. It depends on available system resources, and the cost of licensing more application servers.

It is recommended the Report Server instance be given higher memory (heap size) allocation due to the nature of Windward Report processes.

The minimal number of instances to take advantage of both features is three, two instances for load sharing and one for a separate report engine.

The correct configuration will depend on the size of the customer database and usage. It may be possible to make an educated guess on the initial number of instances in a load sharing configuration and then fine tune through experimentation.

---

Notes #

Click to create a new notes page