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

Version management

Difference between version and

At line 5 changed 4 lines
!!Project Objective
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 10 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 12 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 14 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 14 added 4 lines
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.
At line 21 changed one line
*Only (1) Report Server should exist for each database
*Only one report server should exist for each database
At line 23 changed one line
*Divvy services & watchers between application and report server appropriately
*Divide services & watchers between application and report server appropriately
At line 31 changed one line
*[5th] Implement Oracle specifications to support Clustering/Load Balancing
*Implement Oracle specifications to support Clustering/Load Balancing
At line 34 changed one line
*Feature should not be mandatory (ie) only used as needed
*Feature should not be mandatory (i.e. only used as needed)
At line 38 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 40 changed one line
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.
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 44 changed 3 lines
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">
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 50 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.
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 53 changed 3 lines
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:
#Format: reportHost=xxx|port,yyy|port
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:\\ \\#Format: reportHost=xxx|port,yyy|port
At line 57 changed one line
reportHosts=http://phobos.highlinecorp.com:7779/ePersonality_AS07@12413
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.
At line 59 removed 2 lines
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.