The combination of in-memory calculation, amazing design and years of optimization have resulted in IBM TM1 and Planning Analytics being renowned as one of the fastest real-time analytical engines on the market. The default settings you get "out of the box" is all that is required to have a fast TM1 model. This article focuses on taking it a step further using the many parameters (over 100) which allow you to tune your system to get maximum performance.
MTQ
Multi-threaded querying allows you to enable multiple cores to conduct queries. This feature will provide you with significant performance improvements, especially for large queries with lots of consolidations. An optimal number of cores (sweet spot) needs to be established to achieve the maximum performance. Ensure you conduct various tests to find the "sweet spot" and maximize the performance. Be cautious to not exceed your licensing arrangements — ensure you have enough PVU licenses.
MTFeeders
MTFeeders is a parameter from Planning Analytics (TM1 server v11). By turning on this parameter in tm1s.cfg, MTQ will be triggered when recalculating feeders:
CubeProcessFeeders()is triggered from a TM1 processA feeder statement is updated in the rules
Construction of feeders at startup
MTFeeders will provide significant improvement but does not support conditional feeders. If you are using conditional feeders where the condition clause contains a fed value, you have to turn it off. To turn on MTFeeders during server start-up add MTFeeders.AtStartup=T.
ParallelInteraction (TM1 only)
This feature is turned on by default in Planning Analytics (TM1 11+). You need to set it to true only if you are still using TM1 10.2.
Parallel interaction allows for greater concurrency of read and write operations on the same cube objects. It can be crucial for optimizing lengthy data load processes. Instead of loading all data sequentially, you could load all months at the same time (Parallel loading), allowing you to segment your data and leverage multiple cores to simultaneously load data into cubes.
MaximumCubeLoadThreads
This parameter impacts only the start-up time of your PA/TM1 instance. It specifies whether the cube and feeder calculation phases of the server loading are multi-threaded. Particularly useful if you have many large cubes and there is an imperative to improve performance upon server start-up. It is recommended that you specify the maximum amount of cores – 1.
If you are using Planning Analytics, you should use the new parameter MTCubeLoad instead.
PersistentFeeders
Persistent Feeders allows you to improve the loading of cubes with feeders, which will also improve the server start-up time. When you activate persistent feeders, it creates a .feeders file for each cube that has rules. Upon server startup the TM1 server will reference the .feeders files and re-load the feeders for cubes.
It is best practice to activate persistent feeders if you have large cubes with an extensive number of fed cells. In many cases start-up time can be significantly reduced — examples of 80-90% reduction are common.
Things to look out for: Feeders are saved to the .feeders file. Therefore, even if you remove a particular feeder from the rule file it will remain in the .feeders file. You will need to delete the .feeders file and allow TM1 to re-generate it.
Other parameters which will improve user experience
AllRuleCalcStargateOptimization — Can improve performance in calculating views that contain only rule-calculated consolidations
UseStargateForRules — By default when retrieving a calculated cell, the value will be retrieved from a stargate view stored in memory. In some instances using a stargate view can be slower, so you can turn it off with
UseStargateForRules=FViewConsolidationOptimization — Enables or disables view consolidation optimization. Increases performance but increases memory required
CalculationThresholdForStorage — The number of cells needed as minimum before stargate view creation is triggered. Set to a low number to maximize caching but increase memory
MaximumViewSize — If the view memory reaches the threshold it will abort view construction rather than the client waiting forever
CheckFeedersMaximumCells — If a user tries to check feeders from a cell that is too many cells in the consolidation, it will refuse rather than cause a long hang
MaximumUserSandboxSize — Stop server using excessive memory in case users try to do very large sandbox changes
LogReleaseLineCount — If admins are doing transaction log queries, this stops users getting locked for a long time
StartupChores — Set up a chore which runs when the server starts to cache views, giving users better performance
SubsetElementBreatherCount — Allows lock on subset to be released when there are other requests pending
UseLocalCopiesForPublicDynamicSubsets — Improve performance by not invalidating and causing write lock of the public dynamic subset
JobQueuing — Turns on queuing for Personal Workspace or Sandbox submissions
JobQueueThreadPoolSize — Manages all user sandbox commits into a job queue so users don't wait
All the parameters in the tm1s.cfg file are now dynamic in IBM Planning Analytics, meaning they can be changed with immediate effect.