This page (revision-14) was last changed on 26-Nov-2021 10:22 by rforbes

This page was created on 26-Nov-2021 10:22 by jmyers

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
14 26-Nov-2021 10:22 11 KB rforbes to previous
13 26-Nov-2021 10:22 11 KB rforbes to previous | to last
12 26-Nov-2021 10:22 11 KB jmyers to previous | to last
11 26-Nov-2021 10:22 11 KB jmyers to previous | to last
10 26-Nov-2021 10:22 11 KB jmyers to previous | to last
9 26-Nov-2021 10:22 11 KB jmyers to previous | to last
8 26-Nov-2021 10:22 11 KB jmyers to previous | to last
7 26-Nov-2021 10:22 14 KB jmyers to previous | to last
6 26-Nov-2021 10:22 14 KB jmyers to previous | to last
5 26-Nov-2021 10:22 14 KB jmyers to previous | to last
4 26-Nov-2021 10:22 14 KB jmyers to previous | to last
3 26-Nov-2021 10:22 14 KB jmyers to previous | to last Load Sharing & Separate Report Server ==> LOAD SHARING AND SEPARATE REPORT SERVER
2 26-Nov-2021 10:22 14 KB jmyers to previous | to last
1 26-Nov-2021 10:22 14 KB jmyers to last

Page References

Incoming links Outgoing links
LOAD SHARING AND SEPARATE REPORT SERVER
LOAD SHARING AND SEPARATE REPORT SERVER

Version management

Difference between version and

At line 1 changed one line
[{TableOfContents }]
Load Sharing & Separate Report Server
Project Objective
The overview should outline the business intent, purpose and scope of the project. (1-2 sentences)
The purpose of this project is to immediately 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 large reports, and many users 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, a customer can choose to use one or the other, or both as needed. For example, a larger customer may choose to have 4 load sharing application instances and one report server application instance pointing to a single database.
Only one project document is needed, since both features use some common logic and configuration is similar. There are a few differences with set up, and they are noted below.
Project Iterations
An iteration is a deliverable outside of PD. The goal of each iteration should be stated clearly. This section should be updated to show the developer involved and the date completed.
1st Iteration - DK20110401 - Release of major changes to support load sharing & separate report engine
2nd Iteration - Proposed - Split services & watchers between application and report server appropriately
3rd Iteration - Proposed - Report Server Queue - implement maximum number of simultaneous reports
4th Iteration - Proposed - Trim unneeded code from report server to reduce EAR size
5th Iteration - Proposed - Load Sharing becomes more sophisticated Load Balancing & Clustering
At line 3 changed one line
!!!LOAD SHARING AND SEPARATE REPORT SERVER
Related CCARE Cases/Defects
A list of the known CCARE Cases/Defects related to the project and any other background material that may be relevant and helpful.
Below is a list of the CCARE cases/defects related to this project:
Case Defect Cust Pri Status Pgm Problem / Enhancement
45537 PD Done Release of initial changes - Report Server
45538 PD Done Release of initial changes - Load Sharing
45595 QA A Keep getting disconnected from the system
At line 5 changed 2 lines
!!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.
Requirements / Features
Outline the specific requirements and features that are being addressed, broken down by topic if the subject area is large. These should be tied to the iterations using [2nd], [3rd], … at the beginning if NOT in the initial iteration so that it is understood by all what will be done and when.
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 (1) Report Server should exist for each database
• Requirement is that this instance is given higher system memory (heap size)
• [2nd] Divvy services & watchers between application and report server appropriately
• [3rd] Limit number of reports to run simultaneously and schedule others (Queuing)
• [4th] Remove unneeded packages from report server EAR file
At line 8 changed one line
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.
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
• [5th] Implement Oracle specifications to support Clustering/Load Balancing
At line 10 changed one line
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.
Common Features
• Feature should not be mandatory (ie) 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
• Must be seamless to user - login as normal and system will forward requests between available instances
At line 12 removed one line
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.
At line 14 removed one line
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.
At line 16 removed one line
Both features use some common logic and configuration is similar. There are a few differences with set up, and they are noted below.
At line 18 removed 10 lines
!!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
At line 29 removed 5 lines
!!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
At line 35 removed 6 lines
!!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
At line 42 changed one line
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.
Development Approach
This is an optional section to describe the steps the developer would go through in fulfilling the project goals.
See Implementation section below.
Implementation
This section MUST be filled out by the developer. It should provide an outline of any business or technical setup required, a list of all processing considerations, and a list of all functions involved in the setup and usage of the feature.
Overview
We have built very configurable deployment options 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.
At line 44 changed 7 lines
!!Application Implementation
!Connections
There are two types of connections made when launching the application:
#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.
#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">
Application Implementation
Connections
There are two types of connections made when launching EPersonality; First, the client must visit a link on a web server to download several files which include the java archive (JAR) files containing our code, JARs containing pictures, icons and configuration files, as well as a JNLP file. 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">
At line 53 removed 2 lines
}}}
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.
At line 56 changed 2 lines
!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:
The simplest way for us 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 our changes to support these features were done on the client side connection logic.
At line 59 changed one line
{{{
Configuration File
We created a configuration file 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:
At line 63 changed one line
}}}
At line 66 removed 2 lines
!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.
At line 69 changed 2 lines
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:
{{{
Servlet
We built a small Java Servlet into the application to 'serve up' this information to clients application when they 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:
At line 73 removed one line
}}}
At line 75 changed 2 lines
!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.
Client Side
Now, when launching EPersonality, 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, we have added another step between the original two connections to contact the server and get the correct connection information from the configuration file.
At line 78 changed 9 lines
!!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. All instances must define the deployment type as one of the following JVM arguments:
{{{
Set Up
Deployment Types
The same EAR can be used for all 3 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:
At line 89 changed 4 lines
-Dcom.highlinecorp.deployment=standAlone
}}}
!Instance Options
Load Sharing instances can be deployed in several ways.
-Dcom.highlinecorp.deployment=standAlone (not needed, but available for future use)
At line 94 changed 4 lines
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)
Instance options
Load Sharing instances can be deployed in several ways:
For example, if a customer wishes to use 3 instances for load sharing, they could deploy;
• One instance with 3 Java Processes (JVMs)
• OR Three instances could be deployed with 1 JVM each
• OR The client can mix and match (eg) 2 instances with 1 and 2 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 (1) JVM.
Report Servers should not have any startup cache loaded - configured in AppResources/selfServiceStyle.xml
At line 99 changed 11 lines
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.
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.
At line 111 changed one line
{{{
At line 113 removed 3 lines
}}}
!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.)
At line 119 added 2 lines
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, the client will use it to connect to the same RMI port every time (ie) 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.
At line 118 changed one line
{{{
At line 121 changed one line
}}}
At line 124 changed 2 lines
!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|IMST#PreferencesTab] tab.
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, you must also specify the network path, rather than the local machine path to the directory on the IMST preferences tab.
At line 127 changed one line
!Suggested Deployments
Suggested Deployments
At line 129 removed one line
At line 134 added 2 lines
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.
At line 132 removed one line
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.
At line 134 removed one line
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.
At line 136 changed 3 lines
----
![Notes|Edit:Internal.LOAD SHARING AND SEPARATE REPORT SERVER]
[{InsertPage page='Internal.LOAD SHARING AND SEPARATE REPORT SERVER' default='Click to create a new notes page'}]
Questions / Additional Notes
This section should contain questions that have been or need to be asked/answered so that the project can be completed.
• What are the specifications needed to support Clustering in an Oracle Application Server?
• Is Clustering easier to support in a WebLogic Application Server?
• Should we consider supporting more than one Report Server instance?
• Can the configuration file be replaced with logic reading connection info directly from OAS?
• Need to form suggested deployment configurations and memory settings (Separate Project)
Development Problems / Issues
Provide an outline of all problems, issues or challenges encountered while doing the development work (or anticipated up front).
Where to put Context Watchers? Since there is only one report server, and there should be only one instance of a watcher for a database, it makes sense to put the watchers in the report server instance. However, the WorkFlowLogsWatcher needs to see online users to be able to send messages, and actions to them. This is why the watchers were moved back into the main application deployment. There is no difference to 'Context Watchers' when deployed in a load sharing configuration, to multiple instances pointing to the same database (current option).
Removing configuration file: Need to research how to get connection information (opmnctl) information directly from Oracle Application Server. However, this removes option to link to other machines, and/or app servers.
Resources Released
This does not need to include java classes but should include icons, style changes and documents.
• Sample ePersonality.JNLP file
• Sample connections.config file
• Deployment descriptor web.xml
• Source code changes
This page (revision-14) was last changed on 26-Nov-2021 10:22 by rforbesTop