Performance Tuning

Numerous settings exist that help to optimize the performance of the IBM Security Verify Access OIDC Provider (ISVAOP) in an environment.

Mapping Rule (JavaScript) Executor

IBM Security Verify Access OIDC Provider (ISVAOP) uses v8 Isolates to execute mapping rules (JavaScript). An Isolate is a standalone copy of the v8 runtime which includes it's own heap manager. Within the isolate you can define multiple Contexts so multiple mapping rules (JavaScript) can be executed without interfering with each other.

You can configure the number of v8 Isolates and maximum number of Contexts per Isolates for the deployment at the provider configuration. The max_load JavaScript configuration entry is used to define the maximum number of Isolates. The max_ctx_in_isolate JavaScript configuration entry is used to define the maximum number of Contexts per v8 Isolates.

Set the 'max_load' entry to the number of max CPU cores available to the IBM Security Verify Access OIDC Provider (ISVAOP) container. For example:

javascript:
  timeout: 5000
  max_load: 16
  max_ctx_in_isolate: 50

📘

Note

Isolates and Contexts require additional memory. The additional memory requirement can be calculated via the rule : (Number of Isolates * Number of Contexts * 8)mb

Connection pools

The IBM Security Verify Access OIDC Provider (ISVAOP) uses connection pools to communicate with various storage layer components for better performance.

Database Connection Pool

You can configure the connection pool for database at storage configuration. For example:

server_connections:
  - name: mypq
    type: postgresql
    conn_settings:
      max_idle_time: 10                                     # Maximum idle time in seconds.
      min_pool_size: 5                                      # Minimum connection pool size.
      max_pool_size: 50                                     # Maximum connection pool size.
      connect_timeout: 5                                    # Connect timeout, in seconds.
      aged_timeout: 30                                      # Aged timeout, in seconds.

Ldap Connection Pool

You can configure the connection pool for ldap at storage configuration. For example:

server_connections:
  - name: ldap_staging
    type: ldap
    conn_settings:                                          
      max_pool_size: 50                                     # Maximum connection pool size.
      connect_timeout: 3                                    # Connect timeout, in seconds.
      aged_timeout: 5                                       # Aged timeout, in seconds.

Redis Connection Pool

You can configure the connection pool for ldap at storage configuration. For example:

server_connections:
  - name: redis-standalone
    type: redis
    conn_settings:                                          
      min_idle_size: 5                                     # Minimum connection pool size.                                       
      idle_timeout: 10                                     # Connection idle timeout, in seconds.
      max_pool_size: 50                                    # Maximum connection pool size. 
      connect_timeout: 5                                   # Connect timeout, in seconds.
      io_timeout: 3                                        # IO timeout, in seconds.

Database

Database is used as token storage and optimal performance of the database is essential for the IBM Security Verify Access OIDC Provider (ISVAOP)'s performance.

Postgres

Each OIDC transaction consists of multiple database transactions. Use the pgbench tool to size the database deployment. If the anticipated OIDC transactions are at 100/sec, size the database for 500 transactions/sec.

Sample sizing for 1000 OIDC transactions/sec:

Resource:
  CPU : 16 cores
  memory : 64 GB
  Disk : 500 GB

Instance level tuning:
   shared_buffers = 6GB
   temp_buffers = 80MB
   max_prepared_transactions = 20
   work_mem = 60MB
   effective_cache_size = 32GB