Siebel Loyalty Administration Guide > Getting Started with Siebel Loyalty >
Optimizing Loyalty Point Block Updates
For Assign Points actions, the points are associated with point blocks. Usually a host would have one point block for base accruals and one point block for each partner. In other words, the number of point block records is small.
This means that, if a deployment that has multiple processes running on multiple servers, all threads that process transactions update one or few records, slowing the performance and limiting the scalability of the engine.
Two System Preferences are available to solve this issue and optimize performance. By default, these system preferences are not defined and do not take effect.
NOTE: This optimization is available only for the batch mode components. It is not applicable to the real-time components.
To optimize loyalty point block updates
- Navigate to the Administration - Application > System Preferences view.
- Enter a value for one or both of the two system preferences described in the following table.
If specified, this should be a number > 0. It indicates that the engine should batch the point block updates and apply it to the point block only after this many transactions have been processed.
If specified this should be a number > 0 and < 100. As the available balance in the point block record becomes low, batching the updates can result in more points being assigned to members than are actually available. In order to prevent this problem, this value will effectively turn off the batching for the point block records whose remaining balance is below the specified percentage value. For other point block records, it will use the batching mechanism.
Example of Optimizing Point Block Updates
Suppose 10,000 transactions are being processed, each generating 10 points, and there is a point block of 100,000 points.
If these system preferences are not specified, then the point block record will be updated 10,000 times, slowing performance.
As an example, suppose the system preferences are set to:
- LOYPointBlockBatchSize = 50
- LOYPointBlockBatchPercent = 2
For the first 9,800 transactions (100-2=98%), the engine will batch the updates and only apply updates after every 50 transactions, resulting in 196 updates (9,800/50) instead of 9,800. This will reduce the processing load for 98% of the transactions.
From the next transaction onwards the point block would have less than 2% remaining balance and so the batching would be disabled resulting in 200 updates.
The total number of updates done would be 396 (196+200), as compared to 10,000 without these parameters. There will be contention during processing of the final 200 transactions, but this will happen for only 2% of the transactions.
After this point block has been used, the next point block will have a 100% balance to start with and will be used with the optimization until it reaches a less than 2% balance.
Server Process Termination and Recovery with Optimization
As the engine processes the batch of 50 transactions, it stores the information about the pending updates in the database in special system records (and not in memory). One system record is created for each point block by each server process as it uses the original point block record.
After every 50 transactions, the used amount from the system record is added to the parent record used amount and is reset to zero for the system record. This is called point block synchronization. Synchronization is also done in the following conditions:
- If the engine crashes or the server is brought down abruptly, no information is lost. The next time the engine starts, the synchronization is done again.
- If the engine is terminating normally, the engine does the synchronization before exiting. So, all system point block records will have a used amount of 0. (Note that these records are not exposed in the user interface).
- If the engine is running in a continuous mode (LOYEngineNumberOfRuns = -1) and there are no more transactions to process and the engine is going to sleep.