Best practice use of Parallel Interaction

To obtain maximum performance gains provided by Parallel Interaction, follow these best practice guidelines.

Parallel Interaction (PI) is a server configuration that improves response time of writing data by removing lock contention resulting from concurrent cube data access (when the system reads data or when the system writes data). When enabled, Parallel Interaction changes the Cognos® TM1® Object Locking model so that write operations are not blocked by concurrent data read or data write operations to the same cube (or dependent cubes based on rules). Read operations always includes the most current write activity as of the time the read operation begins.

Comparisons between Cognos TM1 with or without Parallel Interaction show significant performance improvements for writer response time and an overall greater throughput of transactions with test cases that simulate high user concurrency.

Cognos TM1 Parallel Interaction provides immediate writer response times in cases where writer performance had been negatively impacted without Parallel Interaction. Improvements include:

Support of concurrent writers executing high-level data spreading input
Support of high user counts for readers demanding instantaneous access to freshly-entered data
Maintenance of more recently-updated environments during cube data loads over the course of a day
Execution of TurboIntegrator Data Allocation processes sourcing data from Input Cubes
Execution of TurboIntegrator Data Manipulation processes to incrementally build Reader Cubes sourcing data from Input Cubes

Parallel Interaction is useful for any Cognos TM1 application involving writeback activity. Sufficient server CPU cores are needed to realize the benefit of Parallel Interaction and to process the greater throughput of concurrent read and write operations. Sufficient cores also ensure that any remaining "blocking" activity resulting from meta data maintenance does not interfere with writer performance. Parallel Interaction does not improve query performance, so it is not recommended for Cognos TM1 read-only applications.

Parallel Interaction impact on Cognos TM1 server core utilization

If the environment has sufficient server cores to process the incremental transactional activity, using Parallel Interaction in Cognos TM1 for work that is subject to reader/writer contention generates higher transaction throughput than similar work performed in previous versions of Cognos TM1 . With Parallel Interaction writers are no longer blocked by concurrent readers or other writers to the same cube (and dependent cubes); therefore, the Cognos TM1 server cores tend to process more transactions during periods of high concurrency.

Customers observe significantly higher CPU utilization using Cognos TM1 Parallel Interaction during periods of high read/write concurrency as compared to previous versions of Cognos TM1 .

Insufficient Cognos TM1 server core capacity may negatively impact the potential performance advantages of Parallel Interaction. Cognos TM1 customers upgrading to Cognos TM1 9.5.2 or later from prior versions should monitor Cognos TM1 server CPU utilization when operating with Parallel Interaction to ensure that server cores are not "saturated," which is indicated by a greater than 80% server utilization for moderate to long periods of time. If use of Parallel Interaction results in Cognos TM1 Server core saturation, add additional cores to the server as available or consider a server with more available cores.

Parallel Interaction impact on reader performance

In scenarios involving high volume mixed read/write activity, the read operations may be slightly slower in Cognos TM1 9.5.2 or higher with Parallel Interaction On compared to Cognos TM1 9.5.1. This situation occurs because with Parallel Interaction, writers utilize CPU resources more efficiently and compete with readers for those resources. With the greater throughput of write activity in Cognos TM1 9.5.2 or higher, Parallel Interaction more frequently invalidates internal caches which can also negatively impact reader performance.

Parallel Interaction does not yield performance benefits for readers in read-only Cognos TM1 applications.

Parallel Interaction's impact on Cognos TM1 Semaphore best practice

Prior to Cognos TM1 9.5.2, customers employed a TurboIntegrator Best Practice called "Semaphore" to prevent TurboIntegrator process "thrashing" (a wasteful situation of successive rollbacks and retries which results in performance issues for the end users). Thrashing is caused by concurrent execution of TurboIntegrator processes that locked the same objects and blocked each other.

For instance, consider an end user data input Websheet with an Action Button that calls a process to copy data from input cubes to a reporting cube. This operation could result in concurrent execution of a process that performs a read operation followed by a write operation. During periods of high concurrency, the write operation could encounter a locked cube (as a result of another write operation), causing the process to rollback its work and re-initiate the process. Subsequent re-tries by the process could also encounter a locked destination cube, causing another rollback and resulting in a thrashing scenario that negatively impacts end-user performance.

The Cognos TM1 Semaphore Best Practice approach required the TurboIntegrator processes to update a common cube in the Prolog section to register themselves for execution; this action meant that if the process held the lock on the semaphore cube, it would execute to completion without interference from locks by concurrently-run processes. If the attempt to write to the common cube in the Prolog encountered a lock, the rollback time had, by comparison, a minimal impact on performance. With Parallel Interaction, concurrent writes to the semaphore cube do not cause serialization; all writes occur in parallel.

With Cognos TM1 9.5.2 Parallel Interaction, the Cognos TM1 Semaphore Best Practice as described above may not be needed or may need to be adjusted to ensure a similar behavior. If the process is only reading and writing data, the Semaphore approach is no longer needed to achieve better performance. In this case the concurrent processes run to completion with no locking behavior.

If the process is performing meta data maintenance, a new TurboIntegrator function called synchronized() is available to ensure that the process doesn't cause unnecessary usage or contention of Cognos TM1 and system resources. For more details, see the topic "Serializing TurboIntegrator processes using synchronized()" in the IBM Cognos TM1 TurboIntegrator Guide.

Performing maintenance to a common dimension might be a suitable alternative. The Best Practice for using a dimension as a semaphore controlling object requires that the Base TurboIntegrator process calls a Dimension Semaphore process using Execute Process in the Prolog tab. The Dimension Semaphore process will simply insert a dummy element in the controlling dimension, thereby locking that dimension so no other process that maintains that dimension can proceed. The Base process then removes the dummy element in the Epilog tab.

Parallel Interaction impact on use of Batch Update Start and Batch Update Finish Wait

The existing Best Practice to improve data loading performance executes multiple TurboIntegrator processes in parallel, wrapping each of them with Batch Update Start/Batch Update Finish Wait functions. This approach is commonly used to split up a large data load into several smaller data loads (the count depends on the cores available to manage the data load). Executing processes within Batch Update functions allows each process to operate independently up to the point of taking an IX lock on the target cubes. At that time the first finishing process updates the cube and the others follow sequentially. The end result is a faster data load than a single TurboIntegrator process.

Parallel Interaction allows for simultaneous execution of processes reading and/or writing to the same cube (none of the data loading processes blocking the others) without the need for Batch Update Start / Batch Update Wait Finish. Remember that processes doing meta data updates result in blocking actions.

Cognos TM1 9.5.2 tests with Parallel Interaction On compared with simultaneous data loads using Batch Update reveal that performance is faster without Batch Update. Therefore, when Parallel Interaction is On, it is best to remove the use of Batch Update from TurboIntegrator processes.

For read-only environments where Parallel Interaction is Off, Batch Update Start/Batch Update Finish Wait remains a Best Practice for increasing the performance data loading using simultaneous data loading TurboIntegrator processes.

Parallel Interaction impact on Cognos TM1 server memory

Internal testing comparing Cognos TM1 9.5.1 to Cognos TM1 9.5.2 with Parallel Interaction have shown the Cognos TM1 9.5.2 Server to allocate between 10% to 30% more RAM than the Cognos TM1 9.5.1 server. Some of this increased memory use is due to the internal structures created by Parallel Interaction, however the additional throughput of transactions and their impact on View Cache is also a contributing factor. Plan for 30% more memory usage with Cognos TM1 9.5.2 than with prior versions of Cognos TM1 .

Operations that cause object locking and potential performance delays

Parallel Interaction greatly improves writer performance and provides predictable performance as reader and writer user counts scale. However, there are Cognos TM1 operations that can mask the benefits of Parallel Interaction by locking objects resulting in response-time performance delays.

Establishing Cube Dependencies

To ensure proper data integrity and cache management in cross-cube references in rules (DB statements or ATTRN/S statements), internal relationships (dependency) between cubes must be created. Establishing the cube dependency is a quick operation, but when it is performed as part of a long running view or TurboIntegrator process, it blocks concurrent read and write activity to the dependent cube (Cube A feeds Cube B, so Cube B is "dependent" on Cube A, and the dependency property setting on Cube B blocks activity to Cube B). Once a Cube Dependency is established, it remains valid for the duration of the server session unless it becomes invalidated by a Rule file or dimension maintenance.

During Server load, Cognos TM1 establishes cube dependencies based on feeder statements in rule files. Feeder statements with data-dependent cube references or rules files containing ATTRN or ATTRS functions do not establish Cube Dependencies during server load; rather those dependencies are established during a first-time query or data update invoking these cross-cube rules.

To improve this situation, create a TurboIntegrator process that establishes all potential cube dependencies in the model using the AddCubeDependency function for each cube-dependent relationship established by rules. The process containing these explicit Cube Dependency functions should be executed immediately following a Cognos TM1 Server Startup, after rule file changes, and following dimension maintenance. This activity quickly establishes server-wide cube dependencies and eliminates the possibility that a long running query or process will trigger a cube dependency during periods of user activity that might block objects and cause contention issues for concurrent readers and writers.

Cube dependencies can be determined by scanning rules files for DB statements and ATTRN and ATTRS functions. An ATTRN/S function creates a dependency on the base cube's corresponding element attribute cube. Alternatively, a system administrator can add the following statement to their Tm1s-log.properties file to have Cognos TM1 log each time it creates a cube dependency:
```
Log4j.logger.TM1.Cube.Dependency=INFO 
```
Entries in the log file will look like the following:
```
9968   []   INFO   2011-03-28 19:18:21.718  TM1.Cube.Dependency 
```
```
Adding cube dependency: cube "SalesCube" depends on cube "PriceCube"
```
In this example, PriceCube is the base cube and SalesCube is the dependent cube. The correct application of this dependency when creating an explicit AddCubeDependency function is as follows:
```
AddCubeDependency(‘PriceCube','SalesCube') 
```
See Understanding Cube Dependency for more information.
ViewConstruct in a TurboIntegrator Process

Use a ViewConstruct function in TurboIntegrator processes to pre-cache a view to improve performance for subsequent View execution (assuming the cache has not been invalidated). This function blocks reads and writes to the View's cube for the duration of the process.

See the ViewConstruct function in the IBM Cognos TM1 Reference Guide.
Element Maintenance

Element Maintenance will cause blocks to readers and writers of any cube containing the maintained dimension. Contention issues may arise when the dimension is maintained as part of a longer running TurboIntegrator process. Isolate meta data maintenance from data maintenance in distinct TurboIntegrator Processes so that the meta data maintenance operation doesn't carry its lock throughout the data maintenance operation (which is non-blocking with Parallel Interaction). This goal can be accomplished in separately-executed Chores or by using the TM1RunTI utility to execute processes external to Cognos TM1 .

The TM1RunTI utility was provided in TM1 9.5.2 minor follow-up release and is part of the standard installation as of Cognos TM1 10.1.0.
Updating an Alias

Updating an alias attribute causes blocks to readers and writers of any cube containing the maintained dimension. Contention issues arise when the dimension is maintained as part of a longer running TurboIntegrator process. Isolate alias maintenance in TurboIntegrator Processes to lessen the blocking impact.