Sizing Guide

Minimum Sizing

The minimum sizing for an instance of the IBM Security Verify Access OIDC Provider (ISVAOP) is defined in the following table:

Note that the sizing requirements for each individual environment are different.

Determine the Sizing for an Environment

The sizing for different elements of an IBM Security Verify Access OIDC Provider (ISVAOP) container can be impacted by different environmental factors.

Disk

The main factor that impacts the amount of disk space that is needed for an IBM Security Verify Access OIDC Provider (ISVAOP) container is the amount of logging that is sent to disk. If no debug logs are enabled, and the request log is sent to the console of the container, very little extra disk space is required. However, if any file based logging is enabled, it can have a large impact on the amount of disk space that is needed.

CPU

The amount of CPU that is allocated to a container impacts the throughput of the ISVAOP, and is mostly noticeable when CPU-intensive operations, such as encryption, are being performed. Monitor the CPU utilization of each individual container during periods of heavy activity and adjusted the amounts as needed. For production use, reserve at least 4000m (millicpu).

Memory

The main factor that impacts the memory requirements of the container is the maximum number of concurrent user sessions that are stored by the container.

The allocated memory for the container must be large enough to hold the IBM Security Verify Access OIDC Provider (ISVAOP) server (approximately 500 Mb), and a fully populated user session cache.

Sessions

Each user session can consume up to 10 Kb of memory. The maximum number of sessions that are stored by the system is controlled by the max_entries configuration entry in storage.yml file. By default this value is set to 60000 entries. After the session cache reaches the maximum configured size, older entries are removed from the cache, which makes way for a new session that uses the Least-Recently-Used (LRU) algorithm.