System Sizing Guide
Overview
Getting the best performance in production environments requires a properly configured system. The most critical elements of that configuration surround JVM memory usage and garbage collection settings. This section covers:
-
a subset of JVM options relevant to the sizing and tuning of the Oracle Health Insurance application
-
sizing guidelines for the JDBC Connection Pool
JVM Options
A full list of JVM options can be found in the Java documentation. The following are relevant for OHI Components applications:
Setting | Value | Description |
---|---|---|
-Xmx |
Maximum java heap size. |
|
-XX:+UseG1GC |
UseG1GC |
Specifies that the G1 garbage collector will be used. |
Heap size does not determine the amount of memory the JVM will use.
Java will allocate a certain amount of memory for the native part of the JVM, as well as a per thread call stack and reserved code cache for JIT compilation. The native part of JVM allocation can not be influenced and depends on a number of factors including platform and heap heuristics.
ADF UI Related Memory Sizing
Oracle recommends allocating 5 Megabytes of heap per tab per user session. A session maps mostly directly to a user, and a tab is an OHI Components major UI element. For example: if someone is using the OHI Claims application and has 3 tabs open in the browser (e.g. a tab for searching claims and 2 tabs for changing claims) the total heap size allocated for the users session is 15 Megabytes. Note that the number of tabs is limited to a maximum of 15 per user.
Processing Related Memory Sizing
Oracle recommends allocating 50 Megabytes of heap per processing thread. The maximum number of task or activity processing threads is controlled by the Core Work Manager Max Threads Constraint that can be set via the WebLogic Console.
Web Services Related Memory Sizing
Similar to the sizing for task or activity processing threads, Oracle recommends allocating 50 Megabytes of heap for servicing a Web Service request.
Working Space Memory
Once the UI and processing contributions have been calculated, the entire value should be increased by 30%. This accounts for working space for the garbage collector. Oracle recommends the use of the through put collector (concurrent mark and sweep or CMS) as well as the parallel new generation collector. Both of these collectors require extra working space for carrying over objects during concurrent collection.
Sample Worksheet for heap size calculations
Base Memory |
1024m |
|
UI Memory |
450m |
30 Users * 3 Tabs * 5 Megabytes per tab per user |
Processing Threads |
16 |
|
Threads for servicing Web Services requests |
16 |
|
Megabytes per Thread |
50 |
|
Processing Memory |
1600m |
(16 + 16) * 50 |
Total Memory |
3074m |
Base Memory + UI Memory + Processing Memory |
Heap Setting (-Xmx) |
~4000m |
3074Mb * 1.3 (garbage collector overhead) |
In this scenario, the -Xmx value would be set to approximately 4000 Megabytes in the shell script for setting environment variables for the OHI Oracle Health Insurance application.
Allocating too little Memory
Allocating too little memory can have significant performance impacts. It can lead to garbage collector issues, system freeze and severe system performance issues.
Allocating too much Memory
Allocating too much memory can lead to lengthy garbage collection pauses and lengthy memory defragmentation (also known as compaction). That in turn may lead to system failures. Make sure that the maximum heap size does not exceed 8192 megabytes. If more memory is required to service all requests then set up additional managed servers in the same domain / cluster for running the system.
Connection Pool Sizing Guidelines
OHI Components utilize WebLogic Data Sources & Connection Pools to connect to the database. The number of connections in the Connection Pool should be properly sized. This paragraph contains guidelines for that sizing exercise.
Connection Pool management
The connection pool is managed by the WebLogic application server. For example, WebLogic may temporarily test a connection before it is handed to the process that requested it. For determining the size of the connection pool the total amount of connections is corrected for this overhead by increasing it with 30%.
ADF UI Related Connection Pool Sizing
The number of connections for servicing UI requests depends largely on the number of (concurrent) users. Roughly, servicing a user’s request requires the use of one connection. After the system’s response is completed "think time" (before the user initiates a follow-up request) needs to be taken into account. Oracle assumes that a user spends 75% of his time evaluating the response and for initiating the next activity. The formula for determining the number of connections for servicing UI requests is: number of concurrent users * (100-75%) with a minimum of 50 connections for handling UI requests.
Processing Related Connection Pool Sizing
For task or activity processing, the number of database connections required is similar to the amount of processing threads.
Web Services Related Connection Pool Sizing
For handling Web Service request, Oracle Health Insurance use more than one database connection. For auditing purposes, information is logged using a separate connection. As a result, for handling Web Services requests the number of database connections required is: the number of concurrent requests * 2.
Sample Worksheet for connection pool calculations
Users |
40 |
|
ADF UI Database Connections |
50 |
40 * 0.25 = 10 (less than minimum of 50) |
Processing Threads |
15 |
|
Processing Database Connections |
15 |
15 |
Number of concurrent Web Services Requests |
15 |
|
Web Services Database Connections |
30 |
15 * 2 |
Total number of Database Connections |
137 |
(50 + 15 + 30) * 1.3 (management overhead) |
As a result, the maximum number of database connections in the pool should be set to 137. Make sure that the number of sessions that the database can accommodate is larger than that number.