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.