This is the second in a series of articles on IBM Decision Server Insights (DSI) innovation at Salient Process. See IBM ODM DSI Innovation at Salient Process for the initial post outlining the overall list of DSI innovations and coming blogs.
In most Decision Server Insights (DSI) solutions, the majority of memory is consumed by the events stored in event history. To reduce memory requirements, the DSI product can use the backing database to store events offline when they are not needed in memory. Since many DSI solutions are memory bound rather than CPU bound, event paging can reduce the number of servers required to execute a solution, reducing hardware, software, and operational costs.
Event paging is analogous to the memory paging mechanism utilized to implement virtual memory, in which a computer stores program elements on disk storage and retrieves each element only when it is needed in main memory. By keeping program elements not currently required by the CPU on disk storage, less memory is required to execute the program. Event paging in DSI keeps events not required by the current DSI transaction in the backing database and only retrieves them into memory when they are referenced by DSI rules.
There are two mechanisms which determine how long events remain in memory after each use. The eventCacheDuration property in the DSI solution_properties.xml file specifies the amount of time that DSI keeps an event in memory after the event is processed by the system for the first time. After the event cache duration, the event can be simply deleted from memory because it will have already been written to the backing database when the transaction completed.
Events that are referenced by rules after the event cache duration are fetched from the database and restored in memory. The timeToLive property in the Extreme Scale objectgrid.xml file specifies how long to keep events in memory each time they are restored from the database.
While event paging reduces memory requirements, there are tradeoffs involved. Depending upon the frequency with which entities are referenced and how eventCacheDuration and timeToLive are configured, it is possible that many of the events in an entity’s event history will need to be paged in every time the associated rules are evaluated, increasing response time and CPU consumption.
Furthermore, since both eventCacheDuration and timeToLive are system-wide variables, it is not possible to tailor event paging to reflect variations across or within entity types. As a result, variations in response time may be unavoidable and could complicate establishing the ideal settings.
In summary, event paging can provide significant benefits but must be carefully evaluated for each DSI solution to ensure its use is appropriate. Salient can help you determine whether event paging can reduce the cost of deploying your DSI solution and help you determine the optimal settings. For more information or to schedule a free evaluation, send your contact information and a brief explanation of your project to email@example.com. You will receive a reply within two business days.