7 Improving Performance in BRM Cloud Native

Learn how to improve performance in your Oracle Communications Billing and Revenue Management (BRM) cloud native environment.

Topics in this document:

Deploying the CM and DM Containers in the Same Pod

You can improve communication performance between CM and Oracle DM by deploying the CM and Oracle DM containers in the same Kubernetes pod.

To deploy CM and Oracle DM in the same pod:

  1. In the oc-cn-helm-chart/templates directory, rename the dm_oracle.yaml file to _dm_oracle.yaml.

    Renaming the file prevents the Helm chart from creating Oracle DM as a separate pod.

  2. From _dm_oracle.yaml, copy the dm-oracle container definition into the containers section of cm.yaml.

    Copy all configuration that the dm-oracle container references, including its environment variables, ports, probes, volume mounts, and corresponding volume definitions.

    If you enable TLS for Oracle DM, configure its TLS wallet by using the standard BRM TLS wallet settings. For example, you can set ocbrm.dm_oracle.extUserSSLWalletSecret to the Kubernetes secret that contains the Oracle DM wallet. For information about BRM TLS wallet provisioning and wallet-source selection, see "Configuring TLS Certificates for BRM Cloud Native".

  3. In the copied dm-oracle container definition, set SERVICE_FQDN to localhost: 

    - name: SERVICE_FQDN
  value: "localhost"

    CM and Oracle DM run in the same pod and communicate by using the loopback interface.

  4. Copy the Oracle DM annotations from _dm_oracle.yaml to the corresponding annotations section in cm.yaml.

    Include the annotations required for the Oracle DM configuration so that changes to its ConfigMaps trigger the appropriate pod update.

  5. In the cm-pin-conf-config ConfigMap, change the dm_pointer entry so that CM connects to Oracle DM through localhost instead of the dm-oracle Kubernetes service. For example: 

    - cm dm_pointer databaseNumber ip localhost 12950

    where databaseNumber is the BRM database number.

  6. Save your changes to cm.yaml.

  7. Run the helm upgrade command to update your Helm release: 

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile --namespace BrmNameSpace

    where:

    • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance.

    • OverrideValuesFile is the file name and path to your override-values.yaml file.

    • BrmNameSpace is the namespace in which to create BRM Kubernetes objects for the BRM Helm chart.

  8. Verify that the CM pod contains both the CM and dm-oracle containers and that both containers are running.

Tuning Your Application Connection Pools

You can improve an application's performance by tuning the number of threads available to connect with the CM.

When the CM sends a request, it is assigned a thread from the application's connection pool for performing operations. The thread is returned to the pool when the CM completes its operation.

The request is queued if an incoming request cannot be assigned a thread immediately. The request waits for a thread to become available for a configurable period. If a thread does not become available during this time, an exception is thrown, indicating that the request timed out.

To tune the number of threads in an application's connection pool:

  1. Open your override-values.yaml file.

  2. Edit the parameters shown in Table 7-1.

    Table 7-1 Connection Pool Parameters

    Entry Description

    infranet.connectionpool.minsize

    The minimum number of threads that the application spawns when it starts.

    infranet.connectionpool.maxsize

    The maximum number of threads the application can spawn for accepting requests from the CM.

    infranet.connectionpool.timeout

    The time, in milliseconds, that a connection request will wait in the pending request queue for a free thread before it times out. If a pending request is not assigned a thread during this time, an exception is thrown.

    infranet.connectionpool.maxidletime

    The time, in milliseconds, that an unused thread remains in the connection pool before it is removed.

    Important: If the value is too low, threads might be removed and restored too frequently. This can degrade system performance.

    infranet.connectionpool.maxrequestlistsize

    The maximum number of requests that can be held in the pending request queue.

    infranet.connectionpool.reconnectfrequency

    The interval at which the application refreshes its connections to the CM.

  3. Save and close the file.

  4. Run the helm upgrade command to update your Helm release: 

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile --namespace BrmNameSpace

    where:

    • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance.

    • OverrideValuesFile is the file name and path to your override-values.yaml file.

    • BrmNameSpace is the namespace in which to create BRM Kubernetes objects for the BRM Helm chart.

Configuring Application Connection Pools with Multiple CM Replicas

In a cloud native deployment, an application connects to the CM Kubernetes service instead of connecting directly to a specific CM pod. The CM service distributes the application's requests among the available CM pods.

The infranet.connectionpool.minsize and infranet.connectionpool.maxsize entries apply to each client application replica, not to each CM pod. For example, if a client application has five replicas and infranet.connectionpool.maxsize is set to 40, the application can create up to 200 connections across the five replicas.

You configure the pool size based on the application's concurrent workload and the capacity of the CM deployment. There is no need to configure a separate load balancer between an application, such as a REST adapter, and the CM pods.

Use the CM Kubernetes service to distribute opcode requests to the CM pods. As CM pods are added, removed, or restarted, use infranet.connectionpool.reconnectfrequency to refresh the application's connections. When connections are refreshed or re-established, the CM Kubernetes service can distribute them to available CM pods.

Configuring Multiple Replicas of Batch Controller

If you load event files into your BRM cloud native deployment through Universal Event (UE) Loader, you can improve throughput by running multiple replicas of the batch-controller pod. In this case, each pod can select a file from those available in the UE Loader input PersistentVolumeClaim (PVC). When an individual pod copies the file into its local file system for processing, the other input files are distributed among the remaining batch-controller pod replicas. The time a file arrives in the input PVC determines which pod gets to process the file.

To configure the number of replicas:

  1. In your override-values.yaml file for oc-cn-helm-chart, set the ocbrm.batch_controller.deployment.replicaCount key to the number of replicas to create the batch-controller pod.

  2. Run the helm upgrade command to update your Helm release: 

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile --namespace BrmNameSpace

    where:

    • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance.

    • OverrideValuesFile is the file name and path to your override-values.yaml file.

    • BrmNameSpace is the namespace in which to create BRM Kubernetes objects for the BRM Helm chart.

For more information about UE Loader, see "About Rating Events Created by External Sources" in BRM Loading Events.

Deploying Paymentech Data Manager in HA Mode

Paymentech supports only one connection to its batch port at any one time. To support high availability and increase throughput to the Paymentech server, you can deploy two Paymentech Data Manager (dm-fusa) images, each using a different batch port for connecting to the Paymentech server.

Deploying two images provides failover support for dm-fusa. If one dm-fusa deployment goes down, the traffic from CM to dm-fusa will be redirected to the other dm-fusa deployment. The load is also distributed among all dm-fusa deployments.

To deploy two dm-fusa images:

  1. Edit these keys in the configmap_env_dm_fusa.yaml file: 

    DMF_BATCH_PORT_2: "8781"  
DMF_BATCH_SRVR_2: fusa-simulator-2  
DMF_ONLINE_PORT_2: "9781"  
DMF_ONLINE_SRVR_2: fusa-simulator-2

    Note:

    Unlike the batch port, simultaneous transactions can be sent to the Paymentech online port. Thus, the values of DMF_ONLINE_PORT_2 and DMF_ONLINE_SRVR_2 can be the same as or different from that of the first dm-fusa deployment.

  2. Rename the _dm_fusa_2.yaml file to dm_fusa_2.yaml.

  3. Run the helm upgrade command to update the Helm release: 

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile --namespace BrmNameSpace

    where:

    • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance.

    • OverrideValuesFile is the file name and path to your override-values.yaml file.

    • BrmNameSpace is the namespace in which to create BRM Kubernetes objects for the BRM Helm chart.

Using the Paymentech Simulator

For testing purposes, a second deployment of the Paymentech Simulator is provided in the templates directory. To deploy this second version, rename the _fusa_simulator_2.yaml file to fusa_simulator_2.yaml and then update the Helm release: 

helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile --namespace BrmNameSpace

The deployment scripts and configuration files for the Paymentech Simulator are only provided for testing. In a production environment, remove these files:

  • fusa_simulator.yaml

  • fusa_simulator_2.yaml

  • configmap_pin_conf_fusa_simulator.yaml

  • configmap_env_fusa_simulator.yaml