Performance Tuning

There are numerous settings which can be used to help optimise 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 maxinum 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 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 that 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

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

Postgres

Each OIDC transaction consists of multiple database transactions. Use pgbench tool (https://www.postgresql.org/docs/current/pgbench.html) to size the databse deployment. If anticipated OIDC transactions are at 100/sec , size the databse 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