Training

What can you do if TM1 slows down

In a previous article, I explained how Pulse can help you when Excel is hanging. Now we're going to see how Pulse can help you when a user complains that TM1 slow down.

Don't get me wrong, TM1 is fast. It has by far the most powerful calculation engine on the market, but as software it might happen that in rare occasion it slows down.

When one of your user complains that TM1 is slow, it's fair to say that with TM1 you're a bit harmless. Maybe the user is right or wrong, maybe it is just a subjective experience but you cannot be sure.

In this article I'll show you how Pulse can help you to confirm such statement. If the user is right and TM1 is or was slow, you will be able to explain why.

For this example, let's say that Anthony Taylor complains that TM1 is slow.

1. Check User sessions

The first thing you can do with Pulse is to go to the User Sessions and check the Waiting % for this user.

Pulse keeps track of every user sessions. For each user you can see how many % of their time they spent waiting, in the example below, we can see that they all spent less than 1% of their time waiting which is not too bad:

2. check long running operations

You can drill to one specific user by clicking on his name. Let's check the long running operations chart:

By default Pulse will consider as a long running operation everything (run TI, open cube view, spreadsheets...) which takes more than 10 sec. In the example above, we can see that one operation took 460 sec. So now let's find out what is this operation.

3 Check operations

In the operation tab, you can see the details of all operations for a specific time frame. If you click on the left arrow you see exactly what was happening. In the example below you can see that it took 252 sec to retrieve a view from the Wholesale cube:

4. Why it took that much time to open this view

We've found out that there is an issue with the Wholesale cube, now we'll try to find out what is the cause of this issue. In the cube list report you'll see all cubes statistics:

Clicking on the name of the cube (in this example: Wholesale) will display further details of the cube.:

In the example above we can see that the cube as 1.3 millions cells populated and more than 7 millions are fed. When the number of cells is two times higher than the number of populated cells, it clearly means that the cube is overfed.

5. Set up alerts

In order to anticipate these type of situations, you can set up alerts in Pulse which will send you an email if users are waiting for more than a certain time.

Conclusion

in this example, the user was right. TM1 was slow because of a feeder issue in the Wholesale cube. In this scenario, Pulse helped us to find out when the user was waiting and why he was waiting.

Real life example

A similar situation happened at one of our Pulse client. One of their TM1 user complained to the CFO that TM1 is very slow and sometimes he was not able to access his reports. The TM1 administrator was able to find out all the operations which were taking more than 10 sec and he found out that the user was trying to access the TM1 reports at 10 pm while the nightly chores were running.

Pulse allowed the TM1 administrator to investigate the issue and come up with the solution (the user should not access the report at 10pm when the nightly chores are running)..

 

What can you do if Excel is hanging

What can you do when your users are complaining that Excel or TM1 Web is hanging. How do you deal with this situation. Hopefully it does not happen often in the TM1 world but it can happen if:

  • A process which updates metadata is running.
  • A user is opening a very Large spreadsheet.
  • A user is opening a Large cube view.
  • A user is doing a data spreading on a very Large dimension.

Pulse has lots of features which can help you to troubleshoot slow performance, what is more, is that it gives you the tools to find out quickly what could be the cause of the issue.

1 - Check what's happening

Pulse has a Live Monitor features which shows you what's happening on the server. It tells you the amount of CPUMemory used by your TM1 application, the number of users logged in and the wait time. In the example below we can see that Oliver Martin is running a process and Anthony Taylor is waiting:

2- Analyse what happened

With the Pulse Web client, you can see what's happening right now but if you want to know what happened a few minutes ago, you can use the Pulse Thick Client. It allows you to pause and rewind the threads to investigate what happened in the past. It enables you to analyse the event step by step:

In our issue a TM1 process "z.Dim.UpdateLargeDimension" is causing the lock. Now we need to investigate if this TM1 process took more time than usual and if this is the case, we need to find out why.

3 - Check Process Execution History

Pulse keeps lots of information about your TM1 objects, in the process history tab, you can find for all your TI, the min run time, the avg run time and the max run time. In our example, the min run time of "z.Dim.UpdateLargeDimension" is less than 1 sec and the maximum run time is 40 sec:

With this information, we can investigate the cause whether it is because of changes in the TI process or data source

4 - Check each time a process is executed

In the Query tab, you can pick a process or a chore and see each time it was executed between 2 dates. In our example, we can see that the execution time increased the 21/08/2016 from less than 1 sec to 30 sec:

This significant change in run time can be caused by a TI process or data source change. The next section will show how to investigate change in the code.

5 - Look for changes in the code

Pulse has a Change Tracking feature, every change that you make on a TI or a chore are stored in the Pulse Version Control System. In other words, every time an object is changed by a user or the system, it is tracked and logged into Pulse.

In the Change History tab, we can see all changes that happened in our TM1 instance CXMD, you can filter by TM1 objects in order to see only Processes:

6 - Check the history of changes

Clicking on zDim.UpdateLargeDimension process will display the history of changes for the process:

Now we can go through the changes and try to find out which part of the code could be the cause of the execution time increase. Pulse highlights new line added into the code in green and line deletion in red.

In this example, the issue comes from a new line of code which run a new process:

The beauty here is that we do not have to go through all the code to find what could have changed. With Pulse you can easily see what has been updated and when it has been updated.

Now that we have found the issue, you can either open the TM1 process and remove the change or click to a previous version of the TI and click on the Rollback button. It will overwrite the current version of the TI and replace it by a previous version. This feature can be very helpful if you have lots of code lines that you need to update:

Exercise caution when using the Rollback feature on rule files in Production. This feature saves the rule after rollback and saving a rule will create a lock on the TM1 instance. Depending on how long it takes to save the rules, users might be locked.

7 - set up alerts

In order to anticipate these types of situations, Pulse gives you the ability to set up Alerts which will send you emails or even kill a thread when a threshold is reached. For example you can set up an Alert if the wait time is superior to 60 sec or if a process takes more than 100 sec, Pulse will either send an email, kill the thread or both.

Conclusion

Pulse helped us to understand what was happening on the server. We've found out that one user was waiting because another user was running a TI. Thanks to the change tracking capability, we were able to find out which line of code was causing the issue.