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 5 changed 5 lines
!!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.
!!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.
At line 11 changed 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.
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.
At line 13 changed one line
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.
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.
At line 15 changed one line
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.
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 17 changed 7 lines
!!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
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 25 changed 7 lines
!!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
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 33 changed 4 lines
!!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
!!Separate Report Server
At line 41 changed one line
*Only (1) Report Server should exist for each database
*Only one report server should exist for each database
At line 43 changed 3 lines
*[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
*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 47 changed one line
!Load Sharing
!!Load Sharing
At line 51 changed one line
*[5th] Implement Oracle specifications to support Clustering/Load Balancing
*Implement Oracle specifications to support Clustering/Load Balancing
At line 53 changed 2 lines
!Common Features
*Feature should not be mandatory (ie) only used as needed
!!Common Features
*Feature should not be mandatory (i.e. only used as needed)
At line 58 changed one line
*Must be seamless to user - login as normal and system will forward requests between available instances
*Login as normal and system will forward requests between available instances
At line 60 changed 2 lines
!!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.
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.
At line 63 changed 7 lines
!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.
!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">
!!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">
At line 53 added 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 73 changed one line
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.
!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:
At line 75 changed 2 lines
;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 80 changed one line
}}}
At line 83 changed 2 lines
;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:
!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:
{{{
At line 73 added one line
}}}
At line 88 changed 2 lines
;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.
!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.
At line 91 changed 3 lines
!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:
!!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:
{{{
At line 96 changed one line
-Dcom.highlinecorp.deployment=standAlone (not needed, but available for future use)
-Dcom.highlinecorp.deployment=standAlone
}}}
!Instance Options
Load Sharing instances can be deployed in several ways.
At line 98 changed 9 lines
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
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)
At line 108 changed 3 lines
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:
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.
At line 101 added 11 lines
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:
{{{
At line 113 added 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 114 removed 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 117 changed one line
{{{
At line 120 changed one line
}}}
At line 123 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, you must also specify the network path, rather than the local machine path to the directory on the IMST preferences 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, the network path must be specified rather than the local machine path to the directory on the [IMST Preferences|IMST#PreferencesTab] tab.
At line 126 changed one line
Suggested Deployments
!Suggested Deployments
At line 129 added one line
At line 129 removed 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 added 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 added 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 134 removed 22 lines
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