Try Googling “TM1 Performance problem” and a lot of advice comes up. Some of it contains useful information, for example http://www-01.ibm.com/support/docview.wss?uid=swg21454290.

And then there is the “shot in the dark” stuff like this which is only helpful if your problem happens to have this one cause (and is useless otherwise): http://pic.dhe.ibm.com/infocenter/ctm1/v10r1m0/index.jsp?topic=%2Fcom.ibm.swg.ba.cognos.tm1_api.10.1.0.doc%2Fc_tm1serverperformance_n802b4.html

In this blog post we give you a common sense strategy for (1) diagnosing a performance problem and (2) avoiding performance problems in the first place.

Tip 1: Narrow down the problem

Any TM1 application is dependent on several separate but inter-related components. These include the TM1 server computer, the TM1 client computer, the web server (IIS or Apache Tomcat), Excel, the web browser, and network throughput. Depending on your setup, there can be others.

Your performance problem may be happening in one of these components, or in more than one at the same time. You cannot begin to solve the problem until you know the cause. And you cannot know the cause until you know exactly which component(s) are displaying symptoms.

To figure it out, you first need to be able to reproduce the symptom(s). Next, you need to design a scientific method that will either eliminate a component as a cause, or prove that a component is a cause.

For example:

• You can eliminate the network as a cause by checking to see if the symptoms occur when you run the client (Excel Perspectives, TM1 Web etc) directly on the TM1 Server computer.
• You can prove that the TM1 Server is not slow to respond to users because of locking, by monitoring activity on TM1TOP or Operations Console while the symptom is being observed.
• Conversely you can prove that the TM1 server IS slow to respond to users because of locking the same way! I.e. by monitoring activity on TM1TOP or Operations Console while the symptom is being observed.
• Rather than randomly playing with TM1 server configuration settings, hone in on the setting that you think might help, try to understand it, and design a test that will prove it has made a difference (or not). For example, switching on Parallel Interaction will not help if the system is slow with only a single person logged in!

It is very important to make sure that each test you do will clearly answer one specific question. Test design is not always easy, and is thus worth putting some thought into.

Tip 2: Always Use Real Data

There are two important reasons to design, develop and test your TM1 application with real data, and real data volumes.

1. The data always contains surprises. Sometimes they are surprises of data quality, and sometimes of data patterns and relationships. For example you may assume that the customer field in the source data system is a validated field, and discover that it is not (“ACME Incorporated” vs “ACME Inc.”). Or you may assume that certain fields are always populated, or that Business Line X does not sell product Q (when in fact it did – once!). With made up test data you can never be sure that you are getting the full picture needed for a good design, and in our experience it is of very limited value to even try.
2. Good design is all about trade-offs and compromise: maintainability and flexibility vs speed and complexity. Never underestimate the benefits of keeping the system simple and flexible: this can be measured in the Total Cost of Ownership (TCO) in the long run. It is therefore important to understand how the patterns of data and its volumes will impact performance as early as possible in the design and development process. You do not want to assume the worst, and introduce more complexity – at higher development and testing cost - than is warranted, neither do you want to blithely assume that the TM1 rule you wrote with 5 test numbers in the system is going to perform the same way once 5 years of data have been loaded. Developing and testing with real data in real volumes from the beginning will enable you to make informed decisions early in the process.

Try Googling “TM1 Performance problem” and a lot of advice comes up. Some of it contains useful information, for example http://www-01.ibm.com/support/docview.wss?uid=swg21454290.

And then there is the “shot in the dark” stuff like this which is only helpful if your problem happens to have this one cause (and is useless otherwise): http://pic.dhe.ibm.com/infocenter/ctm1/v10r1m0/index.jsp?topic=%2Fcom.ibm.swg.ba.cognos.tm1_api.10.1.0.doc%2Fc_tm1serverperformance_n802b4.html

In this blog post we give you a common sense strategy for (1) diagnosing a performance problem and (2) avoiding performance problems in the first place.

Tip 3: Always Test as You Go

During the development cycles, make functional testing and basic performance testing an inherent, continuous part of your development process EVEN IF there is a full testing phase planned towards the end of the project. Why? It is easier and cheaper to address a nascent performance problem at the moment its cause is introduced to the system than later, when it is buried within a much larger model with complex dependencies.

Functional testing is important as part of this because it does not matter if your TM1 rule is quick, or your TI process is blindingly fast – if they do the wrong thing and if you are not able to tell whether they are doing the wrong thing, you should not have started development in the first place!

So every time you write ONE rule, or load ONE NEW TRANCHE of (real) data, do something simple like timing the refresh of a relevant cube view: if it used to refresh in 1 second, and now takes 5 seconds .. it is worth taking a closer look before proceeding.

By the time you get to the formal testing phase (User Acceptance Testing and Performance Testing etc.), it should really only be about tying up loose ends.

How QueBIT can help

The QueBIT Team’s experience with TM1 goes back to around 1989, which means that we have had 25+ years to figure out how to get the most value out of TM1 with the least amount of effort! Our proven CARE methodology (http://www.quebit.com/methodology/) is all about empowering our customers and fostering their independence, while being available as trusted partners to support and advise as needed. We hope that these tips will help you tackle and avoid performance issues with TM1 on your own, but if you find you need some help, please get in touch to hear about QueBIT’s performance diagnostic services!