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

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
23 26-Nov-2021 10:22 8 KB ibarr to previous
22 26-Nov-2021 10:22 8 KB rforbes to previous | to last
21 26-Nov-2021 10:22 8 KB jmyers to previous | to last

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 37 added 6 lines
\\ \\
----
!!Self Service Tuning tips:
Some important questions need to be answered before you begin tuning the Self Service environment.
#How many users will be connecting to Self Service currently?
#Does your server meet the minimum requirements for the number of users and more importantly, does it have sufficient resources to scale when the load increases. Please reference the ‘ePersonality Operating Environment’ for more information on the minimum requirements.
At line 44 added 63 lines
!Configuring the Number of Concurrent Self Service Users:
The assumption is made that 500 users will be accessing Self Service currently and self Service is deployed separately from ePersonality. The below configurations changes are based on this fact.
When a Self Service user connects, the first component it communicates with is the HTTP Web server. Therefore, the first component to tune is the HTTP Server. Open the httpd.conf file from the ORACLE_HOME\Apache\Apache\conf\ directory
;(MS Windows Only) MaxRequestsPerChild: Number of concurrent requests the server will allow. As noted, we are tuning Self Service to support 500 current users. Therefore, we can set this parameter to approximately 520 to facilitate the number of user plus any additional overhead.
;(UNIX/Linux Only) MaxClients: Similar to MaxRequestPerChild.
!Tuning the JVM:
For starters the below java options should be used.
*(-Xms# and –Xmx#) initial and maximum heap parameters. To reduce the overhead required by the JVM to manage the heap, we suggest setting these two parameters to the same value
*(-XX:MaxPermSize ) The permanent generation is used to store and load java classes needed by the application. The default value of 64MB is not adequate. Increasing this parameter to 256 will avoid the ‘java.lang.OutOfMemoryError: PermGen space error message.
*(-Xrs) MS Windows Only. All OC4J should be configured with this option to avoid random disconnects from the application. On a Windows platform there are occasions when the administrator logs on/off the console and the JVM does not handle it correctly resulting in the termination of the JVM process.
If you have implemented the above java options and you are still encountering performance issue – further, you suspect the application server is where the problem lies, the below steps can be used to isolate the problem.
*(-verbose:gc) enable this startup java option will allow you to analyze the Garbage Collector, for example:
[GC 66693K->60776K(88216K), 0.0128313 secs]
[Full GC 60776K->49550K(88216K), 0.2769277 secs]
From the above example, there is a minor collection and one full collection.
The GC 66693K->60776K is the combined size of live objects before and after garbage collection respectively.
The 88216K is the total available space – in other words to total heap.
The 0.0128313 secs] is the amount of time it took to perform a minor collection.
From a tuning perfective you need to focus on the available space after garbage collection and the amount of time it took to perform the collection. During this time span your users may experience pauses in the application. Your goal should be to ensure the heap is adequately sized and to minimize the pause time.
There are a number of tuning options available to assist with performance related issues. Here are a few of those options, for a complete list of all the java options, please refer to the Java Virtual Machine Garbage Collection Tuning document.
*(-XX:+UseParallelGC -XX:ParallelGCThreads=2)
The parallel collector is the default collector on server class machines. Increase the parallel GC threads to match the CPU count. The above example implies the server has two CPUs
*(-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode)
The above options will enable the concurrent collector. The concurrent collector will shorten pause times by sharing processor resources with the garbage collector while the application is running. This option should only be used on server class machine that have more than 2 CPUs
!Self-Service Timeout:
The timeout setting for Self-Service will have a negative impact on performance if it is not configured correctly. By default the web server sessions will remain for 30 minutes before there removed. If the server has limited resources this can be an area where resources can be reclaimed.
*(SS_APP_TIMEOUT preference) the timeout value can be set to 5 minutes
*(ORION-WEB-XML) the timeout value can be set to 6 minutes
The goal is to ensure the application times-out before the web server timeout.
*(SS_AJAX_TIMEOUT preference) By default an Ajax request must be completed within 25 seconds. If the request cannot be completed within the allotted time then an Ajax request timed out error message will be encountered. The time required to complete an Ajax request will vary during normal and peak usage and will be different for every client – to determine the appropriate value for your site will require testing.
!!ePersonality
The performance of ePersonality is heavily dependent of the size of the heap and the garbage collector utilized. Please review the above section -tuning JVM options:
High Lines has introduced a new site preference, DB_PRCSS_THREADS which will allow specific update functions to run as a multi-threaded process –in other words the functions will be able to take advantage of multiple processors.
The below list of functions can utilize the DB_PROCSS_THREADS:
[UPCALC]
[UPUNDO]
[UTTP]