You can use configuration (pin.conf) file entries to tune the performance of billing applications. The entries in the billing configuration file are preceded with one of the following:

• -pin_mta: These entries set the default value for all utilities, except non-MTA utilities such as pin_mass_refund and pin_recover.

• The utility's name: These entries override the -pin_mta values for the specified utility.

For example, the following children and fetch_size values are used by all MTA billing utilities. The pin_collect and pin_mass_refund utilities use their own fetch_size values.

- pin_mta children 5
- pin_mta fetch_size 10000
- pin_collect fetch_size 5000
- pin_mass_refund fetch_size 8000

For billing performance issues not related to the configuration file, see "Additional Issues Related to Billing Performance".

The children entry governs how many child threads will process data in parallel. Each child thread fetches and processes one account from the queue before it fetches the next account.

By default, a billing utility uses five child threads to process accounts. You can increase the number of child threads to get better billing performance when the database server remains under-utilized even though you have a large number of accounts. If you increase the number of children beyond the optimum, performance suffers from context switching. This is often indicated by higher system time with no increase in throughput.

Billing performance is best when the number of children is nearly equal to the number of DM back ends and most back ends are dedicated to processing transactions. For information on adjusting the number of DM back ends, see "Configuring DM Front Ends and Back Ends".

To tune the number of children:

1. Open the billing utilities configuration file (BRM_home/apps/fm_bill/pin.conf).

2. In the Performance Entries section, edit the children entry:

   - pin_mta children 5

3. Save and close the file.

The fetch_size entry specifies the number of account records to retrieve from the database and hold in memory before the billing utility starts processing them. In general, this value should be as large as possible to reduce the number of fetches from the database. The maximum possible fetch size depends on the complexity of the application's search results.

When running billing for parent accounts (pay_type 10001), the fetch_size value refers to the number of parent accounts to retrieve. For example, if you have 10,000 parent accounts and each account has an average of 50 children, you would set fetch_size to 10,000 to retrieve all of the parent accounts. If you are running billing for only the children (pay_type 10007), you would set fetch_size to 500,000 to retrieve all of the child accounts.

To tune the account cache size:

1. Open the billing utilities configuration file (BRM_home/apps/pin_bill_accts/pin.conf).

2. In the Performance Entries section, edit the fetch_size entry. For example:

   - pin_mta fetch_size 1000000

3. Save and close the file.

You can tune the performance of the pin_collect utility by using the following configuration file entries:

• per_batch: This entry specifies the number of payment transactions that the pin_collect utility sends to dm_fusa in a batch. For example, if you have 20,000 payments to process and the per_batch entry is set to 5000, the pin_collect utility would send four batches to dm_fusa (with each batch containing 5,000 payment transactions).

• children: This entry specifies how many child threads will process data in parallel. Each child thread fetches and processes one payment transaction from the queue before it fetches the next transaction.

• fetch_size: This entry specifies the total number of payment transactions to retrieve from the database and hold in memory before pin_collect starts processing them. For pin_collect, the optimal fetch size is the number of child threads multiplied by the number of payment transactions in a batch (fetch_size = children * per_batch). For example, if the pin_collect utility has 10 child threads and a per_batch size of 5,000, you would set fetch_size to 50,000.

To tune the performance for the pin_collect utility:

1. Open the billing utility configuration file (BRM_home/apps/pin_billd/pin.conf).

2. In the Performance Entries section, add per_batch, children, and fetch_size entries for pin_collect. For example:

   - pin_collect per_batch 5000
   - pin_collect children 10
   - pin_collect fetch_size 50000

3. Save and close the file.

Some BRM operations, such as searching for group members or searching for items to include on an invoice, can return large amounts of data and cause the Data Manager to fail. In this case, use the following configuration file entries to use a step search to find accounts in charge and discount sharing groups:

• group_members_fetch: Use this entry to search for members of the group sharing object when the parent group contains many members.

• group_children_fetch: Use this entry to search for child accounts in groups when the parent group contains many members.

• item_fetch_size: Use this entry when searching for items.

To filter search results:

1. Open the Connection Manager (CM) configuration file (BRM_home/sys/cm/pin.conf) in a text editor.

2. Uncomment or enter the following lines, as needed:

   - fm_bill group_members_fetch n
   - fm_bill group_children_fetch n
   - fm_bill item_fetch_size n

   where n is the size of pool (memory in bytes) for the step search. The default value is 0.

3. Save and close the file.

For Oracle, you must specify the number of retries to be attempted in case a deadlock occurs during a billing run. For information on the deadlock error, see "Reference Guide to BRM Error Codes".

To specify the deadlock retry number:

1. Open the billing configuration file (BRM_home/apps/pin_billd/pin.conf).

2. Uncomment the - pin_bill_accts deadlock_retry_count entry.

3. Change the deadlock_retry_count entry, if necessary. The default is 20.

   - pin_bill_accts  deadlock_retry_count  20

4. Save the file.

You do not need to restart the CM to enable this entry.

You can ensure that the pin_deferred_act utility processes scheduled actions for an account in the correct order by using the group_by_account entry. When enabled, the utility uses a single thread to process all scheduled actions for one account.

To ensure the sequence of scheduled actions:

1. Open the billing configuration file (BRM_home/apps/pin_billd/pin.conf).

2. Set the group_by_account entry to 1.

   - pin_mta  group_by_account  1

3. Save the file.

You do not need to restart the CM to enable this entry.

Billing utilities fetch accounts and cache them to system memory in the same sequence in which they are stored in the BRM database.

Each account in memory is then distributed to individual child threads (or processes) for billing. This behavior may slow billing performance because of database contention.

You can sometimes improve billing performance by rearranging accounts in system memory prior to distributing the accounts to child threads for processing by using the delta_step entry in the billing utility configuration file.

When a value is specified for this parameter, the billing utilities rearrange accounts cached in system memory based on the parameter value specified. Generally, Oracle retrieves the accounts in the order in which they are found in the database, grouped according to their physical location on the disk.

For example, we might have 100 accounts to bill and 10 threads, as well as 10 database blocks (A, B, C, D, E, F, G, H, I, and J) that each contain 10 accounts. The database returns a list that looks like this: A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, and so on for each block. When BRM starts its threads, each of the 10 threads gets the next available account to process, and the mapping might look like this:

Thread 1  - A1
Thread 2  - A2
Thread 3  - A3
Thread 4  - A4
Thread 5  - A5
Thread 6  - A6
Thread 7  - A7
Thread 8  - A8
Thread 9  - A9
Thread 10 - A10

When a thread finishes processing an account, it takes the next available account from the list, and processing continues until all accounts have been processed. As a result, all of the threads at any given time may be accessing accounts in the same database blocks and vying for the same resources.

You can change the order in which these accounts are processed using the delta_step parameter. For example, to rearrange accounts by selecting and placing every tenth account cached in system memory, and then distribute these accounts to threads for billing, set this entry to 10:

pin_billd delta_step 10

The thread mapping, instead of proceeding one account at a time, would look something like this:

Thread 1  - A1
Thread 2  - B1
Thread 3  - C1
Thread 4  - D1
Thread 5  - E1
Thread 6  - F1
Thread 7  - G1
Thread 8  - H1
Thread 9  - I1
Thread 10 - J1

The delta_step parameter makes it possible for each thread to be working on data from a different area of the database, reducing contention for the same resources and improving billing performance.

You can determine the optimal setting for the delta_step parameter by testing the billing processes and monitoring their performance. By default, this parameter is set to 0, which means that the accounts cached in system memory are not rearranged before distribution.

To rearrange accounts in system memory:

1. Open the billing utility configuration file (BRM_home/apps/pin_billd/pin.conf).

2. In the Performance Entries section, edit the delta_step entry. For example:

   - pin_billd delta_step 10

3. Save and close the file.

• To reduce system load, you can split large billing runs into smaller billing runs. See "Splitting a Billing Run into Multiple Runs" in BRM Configuring and Running Billing.

• You can improve performance of the pin_bill_accts utility by excluding accounts that do not need to be billed. For more information, see "About Suspending Billing of Accounts and Bills" in BRM Configuring and Running Billing.

• When you run the pin_collect utility, you can improve performance by archiving the temporary transmission logs created by the DM for the credit card processing service. See "Checking Paymentech Transmission Log Files" in BRM Configuring and Collecting Payments for more information about the transmission log files.

• You can create billing-related indexes just before you run billing and then delete them when billing finishes. You can add these tasks to the billing scripts. See "Running Billing Scripts" in BRM Configuring and Running Billing and "Removing Unused Indexes".